نيازسنجي اطلاعاتي -دکتر ناصرزاده-932 تفاوت مدلسازی Business و System: تفاوت مدلسازی Business و System
نيازسنجي اطلاعاتي -دکتر ناصرزاده-932 تفاوت مدلسازی Business و System
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
|
چرا هر دو نوع مدلسازي(كسب و كار و سيستمي) مورد نياز است؟ Business Model: به بیان ساده عبارت از متدی است که شرکت در فعالیتهای تجاری در پیش گرفته و با کسب درآمد ثبات خود را حفظ می نماید. در این مدل با توجه به منابع در دسترس و نیاز مشتری، پیشنهادی برای عرضه ارزش مورد نظر مشتری ارائه شده و منافع و درآمد نصیب شرکت می سازد. به تعبیری دیگر;مدل کسب و کار چگونگی کسب درآمد توسط بنگاه را با مشخص کردن جایگاه آن در زنجیره ارزش مشتری تشریح می کند.(مدل کسب و کار ابزاری برای تامین منافع مشتری و منافع بنگاه و کسب در آمد) System Modeling: ايجاد يك مدل براي سيستمهاي نرم افزاري قبل از ساخت يا بازساخت آن، به اندازه داشتن نقشه براي ساختن يك ساختمان ضروري و حياتي است. بسياري از شاخه هاي مهندسي، توصيف چگونگي محصولاتي كه بايد ساخته شوند را ترسيم مي كنند و همچنين دقت زيادي مي كنند كه محصولاتشان طبق اين مدلها و توصيفها ساخته شوند. مدلهاي خوب و دقيق در برقراري يك ارتباط كامل بين افراد پروژه، نقش زيادي مي توانند داشته باشند. شايد علت مدل كردن سيستمهاي پيچيده اين باشد كه تمامي آن را نمي توان يك باره مجسم كرد، بنابراين براي فهم كامل سيستم و يافتن و نمايش ارتباط بين قسمتهاي مختلف آن، به مدلسازي مي‌پردازيم
ابزارهاي مورد استفاده براي هر رويكرد چه ابزارهايي مي باشد؟ Business Modeling : ابزار BPMN System Modeling : زبان UML –استفاده از نرم افزار STELLA تا چه اندازه بايد به مدلسازي كسب و كار اهميت داد ؟ Business Modeling : 1 - برای آگاهی بهتر از مکانیزم های موجود در کسب و کار 2 - برای انجام تغییرات و بهینه سازی اساسی ساختار فعلی کسب و کار و فعالیت های آن 3 - برای نمایش ساختار یک کسب و کار جدید 4 - برای تجربه یک شیوه جدید در کسب و کار و با برای کپی و مطالعه شیوه های مورد استفاه توسط رقیب ها 5 - برای شناسایی موقعیت های برونسپاری در جهان امروز طراحی مدل های کسب وکار به طور فزاینده ای از اهمیت برخوردار شده است چرا که استراتژی ها به آسانی قابل تقلید و تکرار شده اند. ابداع یک مدل کسب و کار نمایانگر حد بالای تغییرات در ابداع محصولات یا فرایند های جدید است. با بهره گیری از مزیت های رقابتی مختلف یک مدل کسب و کار جدید می تواند باعث پرش و جهش قابل توجهی در رقابت های اقتصادی باشد.
|
|
اسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
|
متدولوژيSSADM این متدولوژی یک متدولوژی ساخت یافته است که محصول کشور انگلستان می باشد . داده گرايي : SSADM يک متدولوژي داده‌گرا است و بر روي مدلسازي داده و تشکيل پايگاه‌هاي داده تأکيد دارد. معماري سيستم در متدولوژي SSADM بر مبناي مدلسازي ساختار داده‌هاي زيربنايي سازمان بنا ميگردد. اصل نمودار سازي: SSADM در اصل نمودار سازي با بيشتر متدولوژيهاي ساخت‌يافته مشترک است. اصل نمودارسازي در روش SSADM از اهميت خاصي برخوردار است، به طوري که محصول نهايي مراحل مختلف اين روش در قالب يک يا چند نمودار ارائه ميگردد. درگيرنمودن كاربر: در روش SSADM، شيوه کار به گونه‌اي است که از همان مراحل ابتدايي کاربران درگير عمليات تحليل و طراحي ميگردند و به نوعي متعهد به توسعه سيستم خود هستند. اين ويژگي اساسي، سبب ميشود که در تمامي مراحل، مشخصات سيستم طراحي شده با نيازهاي کاربر منطبق باشد و از خطر توليد سيستمي ناکارآمد جلوگيري گردد. اين امر همچنين سبب ميگردد که نواقص سيستم، پيش از تکميل آن، تا حدود زيادي مرتفع گردد. تضمين کيفيت : تضمين کيفيت يکي از ارکان اساسي در روش SSADM به شمار ميرود. پايان هريک از مراحل SSADM با تضمين کيفيت محصولات آن مرحله همراه است. محصولات نهايي هر مرحله، از نظر کيفيت، تماميت، سازگاري و کارآيي از چندين جنبه توسط مديران، کاربران، توسعه‌دهندگان و کارشناسان به طور دقيق ارزيابي ميشوند. طراحي منطقي پيش از طراحي فيزيکي : در SSADM، پيش از طراحي فيزيکي، نيازمنديها به صورت اصطلاحات منطقي تعريف ميگردند. طراحي منطقي مستقل از سخت‌افزار و نرمافزار انجام ميگيرد. اين امر به توسعه‌دهندگان کمک ميکند که با سرعت مسئله را شناسايي کرده و از بروز موارد غير ضروري در مراحل ابتدايي توسعه جلوگيري نمايند. همچنين قويترين ارتباط ميان کاربران و توسعه‌دهندگان سيستم در مرحله طراحي منطقي به وجود مي‌آيد.
SSADM داراي 5 فاز و 7 مرحله است. فعاليتهايي که در هر مرحله انجام ميگيرد، به شرح زير است : فاز اول : امکان سنجي مرحله 0 ـ امکان سنجي فاز دوم : تحليل نيازها مرحله 1 ـ بررسي محيط فعلي مرحله 2 ـ گزينه يابي سيستم کاري (BSO) فاز سوم : تعيين مشخصات نيازمنديها مرحله 3ـ تعريف نيازمنديها فاز چهارم : مشخصات سيستم منطقي مرحله 4ـ گزينه هاي فني سيستم مرحله 5ـ طراحي منطقي فاز پنجم : طراحي فيزيکي مرحله 6 ـ طراحي فيزيکي نقاط قوت و ضعف SSADM : همانطور که گفته شد متدولوژي SSADM يک متدولوژي داده مدار است و توجه خاصي به طراحي پايگاه هاي اطلاعاتي دارد. اين خصلت مي تواند براي به کارگيري اين روش در طراحي سيستم هاي اطلاعاتي گسترده يک امتياز کلي تلقي گردد. از سوي ديگر اين متدولوژي در سطح کشور، متدولوژي شناخته شده اي به شمار مي رود و بسياري از نهادها و مراکز مرتبط با مقوله طراحي سيستم حداقل به طور کلي با آن آشنايي دارند. قابل دسترس بودن پاره اي از مستندات و مکتوبات تشريح کننده اين متدولوژي در سطح کشور از ديگر مزاياي عمده اين روش است . اکثر ابزارهاي CASE متداول در ايران، اين متدولوژي را پشتيباني مي کنند. يکي از بزرگترين نقاط ضعف SSADM، اهميت نسبتاً ناچيزي است که در آن به مرحله برنامه ريزي راهبردي داده ميشود. به همين دليل اکثر سازمانهايي که به دنبال راه حلهاي جامعي براي سيستم هاي اطلاعاتي خود مي گردند، به سراغ متدولوژيهاي ديگري که به برنامه ريزي راهبردي بهاي بيشتري مي دهند، رفته اند. این متدولوژی دارای محدودیتهایی ( حداکثر موجودیتهای خارجی ، 12 موجودیت ) می باشد و به همین دلیل برای تحلیل سیستمهای بزرگ از این نوع متدولوژی استفاده نمی شود . قابل ذکر است که مستندات این متدولوژی بسیار زیاد می باشد اطلاعات كامل تر در لينك زير
|
|
پاسخ: اسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
|
متدولوژی Rup متدولوژی Rup (Rational Unified Process) یک فرآیند تولید و توسعه نرم افزاری می باشد .مهم ترین هدف Rup اطمینان از تولید نرم افزار با کیفیت بالا می باشد. تولید نرم افزار با استفاده از متدلوژی Rup براساس یک روش تکرار شونده می باشد بدین صورت که در تولید یک محصول تعدادی تکرار در نظر گرفته می شود این تکرارها در فاز های Rup صورت می پذیرد در هر فاز Rup ممکن است چندین تکرار داشته باشیم و در پایان هر تکرار یک محصول قابل ارائه وجود دارد. این محصول در پایان هر تکرار کامل تر شده و در نهایت در آخرین تکرار محصول نهایی ارائه می گردد.
تولید یک محصول نرم افزاری در Rup شامل چهار فاز آغازین (Inception ) ، جزئیات (Elaboration ) ، ساخت (Construction ) و انتقال (Transition ) می باشد . میزان استفاده از نیروی انسانی و زمان صرف شده در هر فاز متفاوت است همان گونه که در شکل زیر مشاهده می کنید فاز ساخت بیشترین زمان و نیروی انسانی را نیاز دارد.
در Rup در ابتدای پروژه یک معماری اولیه تهیه می گردد این امر باعث به حداقل رسیدن ریسک های پروژه در ابتدای کار شده و کیفیت نرم افزار تولیدی را بالا می برد. از دیگر ویژگی های Rup قابلیت توسعه و تغییر نرم افزار براساس سلیقه و نیازهای کاربران و مشتریان می باشد.
کاربرد Rup Rup Methodology براي انواع پروژه هاي نرم افزاري در مقیاس های مختلف از پروژه هاي بسیار کوچک تا پروژه هاي بسیار بزرگ کاربرد دارد. سیستم های اطلاعاتی ،سیستم های نظامی ،سیستم های صنعتی از جمله پروژه هایی هستند که می توان از متدلوژوی Rup در تولید آنها بهره مند شد.
اطلاعات بيشتر در لينك زير |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| هدف از مدلسازی فرآيندهای کاری یک سازمان، ایجاد یک زبان مشترک مفهومی(مبتنی بر استاندارد) و ساده(در قالب اشکال گرافیکی که هم حجم کمتری دارند و هم براحتی توسط کاربر قابل درک هستند)، بین مدیران و کارشناسان سازمان، و تحلیلگران سیستمی میباشد. مدلسازی فرآيندها فعالیتی است که توسط تحلیلگران فرآيندها و به منظور استخراج فرآيندهای موجود و نمایش فرآيندهای جدید در تمام متدولوژی‌ها و استراتژی‌های مهندسی مجدد مورد استفاده قرار میگیرد. در چنین فعالیتی تحلیلگران از ابزارهای مدلسازی برای مدل کردن وضعیت فعلی و وضعیت آینده سازمان استفاده میکنند. مدل کردن فرآيندهای کسب و کار (و یا فرآيندهای سازمانی) یکی از ابتدایی ترین گام های حرکت به سمت بهینه سازی آنهاست. هدف از مدل کردن فرآيندها به نوعی مستندسازی روند انجام اموری است که به هر شکل سازمان در آن دخیل است. وجود یک زبان مشترک و استاندارد به منظور مدل کردن فرآيندها کمک می کند تا این مستندات در شرایط زمانی و مکانی مختلف کارایی خود را از دست ندهند. زبان نشانه گذاريِ مدل سازي فرآيند های كسب و کار (Business Process Modeling Notation(BPMN استانداردی جهت تدوین دیاگرام فرآيندهای کسب و کار است. شامل مجموعه ای از اشکال گرافیکی (هندسی) می باشد که مبتنی بر نمودار گردشی Flowchart توسعه یافته اند. هدف اصلی نشانه گذاريِ مدل سازي فرآيند های كسب و کار فراهم نمودن مدلی است قابل فهم برای تمام افرادی که در کسب و کار سازمان دخیل هستند، مانند سهامداران، مدیران عالی، مشتریان و …. برای مثال در صورتی که ما درک خوبی از روند انجام پیگیری سفارش در سازمان داشته باشيم می توانيم آن را بصورت بهینه و شایسته تر در سیستم مدیریت روابط مشتریان پیاده سازی کنيم. در واقع در این شرایط ما میتوانيم در جهت بهبود کیفیت و افزایش بهره وری، محصول مؤثرتری تولید کنيم که در آن کوتاه کردن مسیر فرآيند، کنترل هزینه، استفاده بهتر از نیروی انسانی و همچنین اطلاع رسانی بهتر به مشتری لحاظ شده باشد. یکی دیگر از مهمترین مزایای مدل کردن فرآيند های سازمانی حفظ پیوستگی در تصمیم گیری های سازمان است. با وجود مدل مستند کسب و کار، پس از تغییرات احتمالی در تیم مدیریت، سازمان دچار سردرگمی و احیاناً تغییرات عمده نمی شود. بلکه تیم مدیریت جدید جهت بهبود مدل قبلی تلاش خواهند کرد و اینگونه است که پیوستگی موفقیت و ثبات یک سازمان حتی پس از مرگ شخص اول آن ادامه دار می ماند. مزیت دیگر، عدم سردرگمی نیروهای انسانی جدید است. در صورت تغییر در پست های سازمانی و یا جذب نیروی جدید، به کمک این مدل، آنها از سردرگمی نجات خواهند یافت و دیگر نیازی نیست تا پس از گذشت یک ماه نیروی جدید درک خوبی از وظایفش و فرآيند عملکردش پیدا کند. سطوح متفاوتی برای مدل سازی فرآيندها وجود دارد: ۱- نقشه فرآيند (فلوچارت های ساده از فعالیتها) ۲- توصیف فرآيند (فلوچارت به همراه اطلاعات اضافه اما نه به اندازه ای کامل که عملکرد آن را به طور کامل توصیف کند) ۳- مدل های فرآيند (فلوچارت به همراه اطلاعات اضافه کامل که فرآيند بتواند تجریه و تحلیل، شبیه سازی و یا اجراشود) ۴- نشانه گذاريِ مدل سازي فرآيند های كسب و کار که هر یک از سطوح نام برده در فوق را پوشش می دهد.مدل سازي فرآيند های كسب و کار برخی از مهمترین مزایای استاندارد سازی علائم مورد استفاده در مدل سازی فرآيند به شرح زیر است: • ایجاد تفکر مشترک و گروهی • تسهیل ارتباطات • ایجاد درک متقابل • راهکار دسترسی به کیفیت • راهکار بهبود مستمر • عامل اعتماد مشتری • عامل رضایت مشتری • راهکار تشخیص و پیشگیری • راهکار کنترل • کاهش هزینه و ضایعات |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| Business Modeling یکی از مفاهیم پایه ای و بسیار مهم در هر کسب و کاری، به ویژه در کسب و کارهای مبتنی بروب و نرم افزاری مدل کسب و کار یا Business Model است. به زبان ساده، این مفهوم بیان می کند که چگونه می خواهید از کسب و کارتان پول در بیاورید. برای نمونه در صنعت نرم افزار های آزاد و باز متن (Open Source) در حدود بیست مدل کسب و کار ساده و مرکب وجود دارد. مدل کسب و کار شرکت کانونیکال (سازنده توزیع لینوکس اوبونتو) تا مدت ها مشخص نبود و هنوز هم کاملا مشخص نیست. این مساله آنچنان اهمیت دارد که سال گذشته انتشارات دانشکده بازرگانی هاروارد (Harvard Business School) -بزرگترین و معروف ترین دانشکده کسب و کار دنیا- کتابی به نام “مدل های کسب و کار باز” (Open Business Models) منتشر نمود. در واقع مدل کسب و کار تشریح می کند که یک بنگاه تجاری چگونه: • مشتری خود را انتخاب کند. • محصولات و تفاوت های قابل ارائه را معرفی کند. • برای مشتری منافع ایجاد کند. • مشتری را پیدا و حفظ کند. • وارد بازار شود (راهبردهای تبلیغی و راهبردهای توزیع) • اهداف آینده را معرفی نماید. • منابع سازمان را هماهنگ سازد. • سود به دست آورد. System Modeling مدل سازی سیستم مطالعه میان رشته ای از استفاده از مدل به مفهوم و ساخت سیستم های در کسب و کار و توسعه فناوری است. یک نوع متداول مدلسازی سیستم مدل سازی تابع است با تکنیک های خاص مانند عملکرد جریان بلوک دیاگرام و IDEF0 . |
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| ابزارهای مدل سازی فرآیند روز به روز گسترش می‌یابند و هر روز امکانات بیشتری را در اختیار ما قرار میدهند. در ذیل به چند ابزار تجاری و Open source اشاره شده است: ًTIBCO Software - TIBCO BPM INTALIO YASPER Appian - Appian Enterprise Macronetics - Automate BPM Ultimus - Ultimus BPM Suite Colosa - ProcessMaker ARIS QPR System Architect متدولوژی طراحی و تجزیه و تحلیل سیستمهای ساخت یافته، یک رویکرد سیستمی برای تحلیل و طراحی سیستمهای اطلاعاتی است. SSADM روشهایی برای ثبت و مستندسازی فعالیتها ارائه میدهد و مشخص مینماید که در هر مرحله از توسعه و ایجاد سیستم چه مستنداتی باید تولید شود. SSADM یک متدولوژی جامع‌نگر است که کم و بیش، تمام مراحل چرخه توسعه سیستم را پوشش میدهد. این متدولوژی در سطح کشور ایران، متدولوژی شناخته شدهای به شمار می‌رود و بسیاری از نهادها و مراکز مرتبط با مقوله طراحی سیستم، حداقل به طور کلی با آن آشنایی دارند. متدولوژی SSADM، در شرایط و موقعیت‌های مختلفی که سازمانها به اجرای فرایندهای توسعه در پروژههای متنوع سیستمهای اطلاعاتی می‌پردازند، مورد استفاده قرار میگیرد. با این وجود، دارای محدودیتهایی نیز میباشد و به همین دلیل برای تحلیل سیستمهای بزرگ از این نوع متدولوژی استفاده نمی‌شود. از جمله معایب SSADM میتوان به صرف وقت زیاد برای مستندسازی، حجم بالای مستندسازی سیستم و انجام مراحل زیاد برای نزدیک شدن به سیستم نرمافزاری اشاره نمود. از سوی دیگر، با تغییر محیط درون و بیرون سازمانها، محققان دریافته‌اند که یک بهترین متدولوژی برای همه موقعیت‌ها وجود ندارد، بلکه باید با توجه به مقتضیات زمانی، مکانی و پروژه‌ای، مورد توافق‌ترین و نه لزوماً بهینه‌ترین متدولوژی را انتخاب کنند. |
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| معرفی RUP RUP یک فرایند تولید نرم افزار است که توسط شرکت rational ایجاد شده است (هم اکنون IBM) و هدف آن کمک به تولید کنندگان و مدیران صنعت نرم افزار است. ´RUP برای جنبه های مختلف تولید چیزهایی مانند نقشها، محصولات، فعالیتها و گردش کار تعریف میکند. تاریخچه ´در طی سه ده تکامل یافته است ´شرکت rational در سال 1995 متدولوژی Objectory را تصاحب کرد و rational Objectory را معرفی کرد. ´در سال 1997 UML توسط OMG استاندارد شد و شرکت rational در متدولوژی rational Objectory همه مدلهای خود را بر اساس این زبان استاندارد نمود. ´متدولوژی rational Objectory برای پوشش جنبه های مختلف تولید نرم افزار توسعه داده شد و متدولوژی جدید RUP نام گرفته شد. ´در سال 1999 با انتشار کتاب ‘The Unified Software Development Process. (Jacobson, Booch, Rumbaugh)’ به عموم معرفی شد. فازها ´آغاز ( Inception): در انتهای این فاز تصمیم گرفته ایم که آیا پروژه را آغاز کنیم یا خیر و این تصمیم پس از تولید یک Business Case گرفته می شود. ´توسعه ( Elaboration): در انتهای این فاز اکثر نیازمندیهای باقی مانده شناسایی شده اند و یک معماری مانع (sound architecture) برای نرم افزار بناشده است. ´ساخت ( Construction): در این فاز با کار روی معماری حاصل از فاز قبل و تولید یک سری اجزاء بر روی نرم افزار در طی تعدادی تکرار، نسخه اول محصول برای اجرا در محیط کاربر ساخته می شود. ´انتقال ( Transition): نرم افزار ساخته شده به سایت مشتری انتقال داده می شود و بررسی میگردد که آیا کاملا نیازمندیهای مشتری برطرف شده است؟ مستندات کاربری نیز تحویل می شود. 
|
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| مدل کسب و کار چیست؟ مدل کسب و کار چارچوبی برای خلق پول و ثروت است. این چارچوب نشان می دهد که یک بنگاه چه مجموعه فعالیت هایی را، چگونه و در چه زمانی می باید انجام دهد تا مشتریان از آنچه که از بنگاه انتظار دارند بهره مند شوند و بنگاه نیز به سود دست یابد. شیوه ای که شرکت، بنگاه یا سازمان برای تولید سود و سرپا نگه داشتن خود انتخاب میکند. مدل کسبوکار بیان میکند که چگونه سازمان برای تولید محصول یا ارائه خدمت ایجاد ارزش افزوده می کند. به بیان دیگر این مدلها که در واقع چارچوبی برای پول سازی هستند، به سه پرسش کلیدی در مورد شرکتها پاسخ میدهند: کدام فعالیتها، چگونه و چه وقت باید انجام شوند؟ پاسخ صحیح به این پرسشها منجر به عملکرد مناسب شرکتها و ارائه مزایای مطلوب به مشتریان شده و در نهایت سود را برای شرکت به ارمغان می‌آورد. مدل سیستمی چیست؟ مدل سیستمی مجموعه ای از تعاملات به هم مرتبط در یک سیستم است که این تعاملات را به شیوه های مختلف به منظور در نظر گرفتن تأثیری که تغییرات طراحی و کارکردی در یک بخش روی بخش های دیگر سیستم می گذارد، انجام می دهد. ابزارهای مدل کسب و کار: Strategyzer Online Business Model Course Business Model Canvas Poster ابزارهای مدل سیستمی: No Magic Cameo Systems Modeler Artisan Studio Sparx Systems Enterprise Architect IBM Rational Rhapsody Lattix Architect Modelio Innoslate Papyrus Software Ideas Modeler SysML Designer Visual Paradigm SCADE System Topcased متدولوژی rup: متدولوژی (Rup (Rational Unified Process یک فرآیند تولید و توسعه نرم افزاری می باشد که در سال 2000 این متدولوژی توسط شرکت Rational ارائه گردید .مهم ترین هدف Rup اطمینان از تولید نرم افزار با کیفیت بالا می باشد. تولید نرم افزار با استفاده از متدلوژی Rup براساس یک روش تکرار شونده می باشد بدین صورت که در تولید یک محصول تعدادی تکرار در نظر گرفته می شود این تکرارها در فاز های Rup صورت می پذیرد در هر فاز Rup ممکن است چندین تکرار داشته باشیم و در پایان هر تکرار یک محصول قابل ارائه وجود دارد. این محصول در پایان هر تکرار کامل تر شده و در نهایت در آخرین تکرار محصول نهایی ارائه می گردد. تولید یک محصول نرم افزاری در Rup شامل چهار فاز آغازین (Inception ) ، جزئیات (Elaboration ) ، ساخت (Construction ) و انتقال (Transition ) می باشد . میزان استفاده از نیروی انسانی و زمان صرف شده در هر فاز متفاوت است. فاز ساخت بیشترین زمان و نیروی انسانی را نیاز دارد. در Rup در ابتدای پروژه یک معماری اولیه تهیه می گردد این امر باعث به حداقل رسیدن ریسک های پروژه در ابتدای کار شده و کیفیت نرم افزار تولیدی را بالا می برد. از دیگر ویژگی های Rup قابلیت توسعه و تغییر نرم افزار براساس سلیقه و نیازهای کاربران و مشتریان می باشد. یک فرآیند در Rup دارای عناصر اصلی زیر می باشد: نقشها(Roles): رفتارها و مسئوليتهايي هستند كه توسط يك فرد يا افرادی از يك تيم در پروژه انجام می شوند از جمله نقش های موجود در یک پروژه می توان به تحلیلگر سیستم ، معمار ، مشتری و کاربر نهایی اشاره کرد. فعاليتها(Activities): كارهايي كه يك نقش در طول پروژه انجام می دهد را فعالیت می گویند . هر فعالیت دارای هدف مشخصی می باشد و تنها به یک نقش منصوب می شود. فعاليتها ممكن است چندين بار در تكرارهاي مختلف پروژه انجام شوند . فرآورده‌ها(Artifacts): فرآورده‌ها در واقع محصولات و خروجی های پروژه می باشند كه در طول فرآيند توليد یک نرمافزار، بوجود می آیند و مورد استفاده قرار می گیرند و بروز رسانی می شوند. دیسیپلین هاي Rup: دیسیپلین ها کارهای به هم مرتبطی هستند که برای به نتیجه رسیدن هدف خاصی از یک پروژه انجام می شوند. در هر دیسیپلین یک گردش کار وجود دارد. متدلوژی Rup از 6 دیسیپلین اصلی که مربوط به تولید محصول و 3 دیسیپلین پشتیبانی و مدیریت که مربوط به تیم و محیط تولید می باشد تشکیل شده است . دیسیپلین های اصلی (مربوط به تولید محصول): مدل سازی کسب و کار (Business Modeling ) : اهداف اصلی این دیسپلین شناخت ساختار سازمان مورد نظر برای تولید و ارائه سیستم به آن سازمان ، بررسی مشکلات موجود و ارائه راه حل برای رفع مشکلات موجود می باشد و هم چنین با ارائه یک مدل Use-Case کسب وکار به تعریف فرآیندها ، نقش ها و مسئولیت های آن سازمان می پردازد. نیازمندی ها (Requirements) : این دیسیپلین به بررسی نیازمندیهای سیستم براساس توافقات انجام شده با مشتری پرداخته و به تعیین حد و حدود سیستم و تخمین هزینه ها و زمان می پردازد. تحلیل و طراحی (Analysis and Design) : تبدیل نیازمندیهای سیستم به طراحی به طوری که طراحی مورد نظر با محیط پیاده سازی هماهنگ باشد و هم چنین ایجاد یک معماری مستحکم از مهم ترین اهداف این دیسپلین می باشد. پیاده سازی (Implementation) : پیاده سازی طراحی سیستم و تولید یک محصول نرم افزای در این مرحله صورت می پذیرد. تست (Test) : تست محصول و بررسی کیفیت و نقایص محصول، بررسی هماهنگ بودن محصول پیاده سازی شده بر اساس طرح از اهداف اصلی دیسیپلین تست می باشد. استقرار (Deployment) : نصب محصول و آماده کردن محصول برای ارائه و هم چنین امکان استفاده از محصول برای کاربران نهایی در این دیسیپلین انجام می شود. دیسیپلین های پشتیبانی و مدیریت (مربوط به تیم و محیط تولید): مدیریت پروژه (Project Management ) : مدیریت پروژه ، مدیریت ریسک ها و از بین بردن محدودیت ها برای ارائه محصولی موفقیت آمیز از اهداف اصلی این دیسپلین می باشد. مدیریت تغییرات و پیکربندی (Configuration & Change Management) : پیکر بندی و اعمال تغییرات لازم با حفظ صحت خروجی های پروژه در این بخش صورت می پذیرد. مدیریت محیط(Environment) : فراهم کردن محیط تولید و ابزارهایی که در جهت پشتیبانی تیم تولید است مانند ایجاد سایت برای سازمان هدف در این بخش صورت می پذیرد . متدولوژی SSADM: SSADM يکي از اعضاي خانواده روشهاي توسعه سيستمهاي اطلاعاتي است که از ابتداي دهه 1980، به عنوان مهمترين روش تحليل و طراحي سيستمهاي اطلاعاتي در انگلستان به کار گرفته شده است. اين روش در ابتدا توسط مهندسين مشاور مديريت سيستمهاي لارمونت و بورچت (LBMS) معرفي شد و سپس با همکاري آژانس مرکزي مخابرات و محاسبات ماشيني (CCTA) که مسئول آموزش کامپيوتر و تأمين سخت‌افزار جهت سازمانهاي دولتي در انگلستان ميباشد، توسعه يافت. این روش داراي 5 فاز و 7 مرحله است. فعاليتهايي که در هر مرحله انجام ميگيرد، به شرح زير است : فاز اول : امکان سنجي مرحله 0 ـ امکان سنجي -آمادگي براي مرحله امکانسنجي -تعريف مسئله -انتخاب گزينه‌هاي امکانسنجي -ارائه گزارش امکانسنجي فاز دوم : تحليل نيازها مرحله 1 ـ بررسي محيط فعلي - پي ريزي چارچوب تحليل -بررسي و تعريف نيازها -بررسي فرآيندهاي موجود -بررسي داده هاي موجود -ترسيم تصوير منطقي خدمات موجود -ارائه نتايج بررسي مرحله 2 ـ گزينه يابي سيستم کاري (BSO) -تعريف گزينه هاي سيستم کاري -انتخاب گزينه هاي سيستم کاري - تعريف نيازها فاز سوم : تعيين مشخصات نيازمنديها مرحله 3ـ تعريف نيازمنديها -تعريف سيستم پردازش مورد نياز -توسعه مدل داده مورد نياز -استخراج کارکردهاي سيستم -بهکرد مدل داده مورد نياز -تهيه نمونه هاي مشخصات -توسعه مشخصات پردازش -تأييد اهداف سيستم -ارائه مشخصات نيازمنديها فاز چهارم : مشخصات سيستم منطقي مرحله 4ـ گزينه هاي فني سيستم -تعريف گزينه هاي فني -انتخاب گزينه هاي فني -تعريف فاز طراحي فيزيکي مرحله 5ـ طراحي منطقي -تعريف محاوره هاي کاربر -تعريف پردازش‌هاي بهنگام‌سازي -ارائه طراحي منطقي فاز پنجم : طراحي فيزيکي مرحله 6 ـ طراحي فيزيکي -آمادگي براي طراحي فيزيکي -ارائه طراحي فيزيکي داده -ارائه نقشه کارکرد اجزاء سيستم -بهينه کردن طراحي فيزيکي داده -تکميل مشخصات کارکردي -منسجم کردن واسط پردازش داده -ارائه طراحي فيزيکي -ارائه گزارش امکان سنجي. |
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| یک مدل کسب و کار مؤثر و قابل اجرا باعث خلق و هدایت ارزش افزوده بیشتری نسبت به سایرگزینه‌های موجود میشود. این مدل ممکن است برای مشتریانی که ارتباطشان را با سازمان قطع کرده اند ارزش‌های بیشتری به‌همراه داشته باشد یا ممکن است به‌طور کلی روشها و شیوه‌های سنتی انجام کارها را کنار گذارد. از سوی دیگر ممکن است مدل کسب و کار به‌علت تفکر نامناسب مؤثر و کارا نباشد زیرا رقیبان مدلهای کسب و کار بهتری را گزینش کرده‌اند. مدل سازی سیستمی نیز توصیفی از نیازمندی ها، ساختار، طراحی و غیره است که می تواند دیدی خاص و در سطح کلان در مورد کسب و کار ارائه دهد. |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| مروری بر متدولوژی SSADM متدولوژی SSADM ( Structured System Analysis Development Method ) این متدولوژی یک متدولوژی ساخت یافته است که محصول کشور انگلستان می باشد . این متدولوژی دارای محدودیتهایی ( حداکثر موجودیتهای خارجی ، 12 موجودیت ) می باشد و به همین دلیل برای تحلیل سیستمهای بزرگ از این نوع متدولوژی استفاده نمی شود . قابل ذکر است که مستندات این متدولوژی بسیار زیاد می باشد .این متدولوژی به طور خلاصه شامل مراحل زیر است : 1.جمع آوری فرمهای پروژه 2.تهیه سناریو 3.تقاضای سیستم میکانیزه 4.زمانبندی 5.دیاگرام متن ( Context Diagram ) 6.شرح موجودیتهای خارجی 7.شرح خطوط جریان داده 8.دیاگرام گردش مستندات 9.دیاگرام گردش داده ها ( DFD ) 10.خلاصه عملکرد سیستم 11.مشکلات و نیازمندیها 12.دیاگرام متن منطقی 13.دیاگرام منطقی گردش داده ها 14.طراحی پایگاه داده 15.طراحی منوی برنامه 16.طراحی فرم ورود داده ها 17.شرح پردازه های جزئی انتخاب راه حل :هدف ، انتخاب بهترین راه حل کامپیوتری برای برآورده کردن نیازمندیهای کاربر است .شرح نیازمندیها :در این مرحله حاصل از مرحله شناخت ، در قالب مدلهای تحلیل و طراحی به صورت دقیق و خلاصه توسط مهندس نرم افزار مشخص میشود . طراحی منطقی : هدف از طراحی منطقی تعیین منطق عملیات سیستم مکانیزه بادر نظر کرفتن نیازهای کاربر است . طراحی فیزیکی : هدف از طراحی فیزیکی تعیین دادها ، پردازه ها ، ورودیها و بالاخره خروجیها با استفاهده از زبان و محیط فیزیکی تعیین شده است . طراحی فیزیکی داده ها : سه نوع عملیات برای طراحی داده ها وجود دارد . این عملیات شامل تعیین محیط فیزیکی و استراتژی طراحی ، طراحی داده های فیزیکی و بالاخره بهینه سازی حاصل از طراحی داده ها است . طراحی رابط داده : چنانچه دیدگاهی که از داده ها و اطلاعات ذخیره شده وجود دارد متفاوت از واقعیت فیزیکی داه ها باشد باید رابطی جهت تبدیل داده ها ایجاد شود . طراحی پردازه های فیزیکی : هدف ، تبدیل طرح منطقی پردازه ها به مدل فیزیکی عملیات در سیستم جدید مکانیزه است . پنج مرحله اصلی تحلیل و طراحی سیستم عبارتند از : طراحی فیزیکی طراحی منطقی شرح نیاز تحلیل نیاز امکان سنجی متدولوژی SSADM SSADM یکی از متدولوژی های شناخته شده تولید سیستم های مکانیزه است .هدف از امکان سنجی ، ارزیابی اولیه جهت قول یا رد پیشنهاد انجام پروزه نرم افزاری است . تحلیلیگر مجرب باید قادر به شناخت نیازها و ارئه راه حل های ممکن برای انجام پروژه بوده ، هزینه های سخت افزار ، نرم افزار ، زمان و افراد لازم برای اجرای پروژه را مشخص نماید .تخمین نا صحیح هزینه ها میتواند برای تحلیلگر و سازمان وی فاجعه آمیز باشد ، موفقیت در امکان سنجی مستلزم تجربه زیاد و برنامه نویسی و شناخت کافی از امکانات سخت افزاری ، ایجاد شبکه ها و ابزار های جانبی کامپیوتر و بالاخره آشنایی کامل با سیستم های عامل ، زبانهای برنامه سازی ، بسته های نرم افزاری و موارد کاربرد آن ها است . در مرحله تحلیل نیازمندیها ، مشکلات سیستم موجود بررسی وراه حل های ممکن ارائه می شود .مسلما لازم است که قبل از ارئه هر راه حلی ، تعریف دقیقی از جزئیات مساله فراهم شود . مهندس نرم افزار با بکار گیری روش نگرش سیستمی در شناخت مسائل باید کمک کند تا افراد و مدیران بتوانند مشکلات را تعیین کنند برای این منظور در نگرش سیستمی به صورت زیر عمل می شود :الف-تعیین عملکرد کلی : ابتدا محیط عملیاتی سیستم مشخص میشود ب- تعیین شبکه عملیات داخلی : برای تعیین عملکرد داخلی ، معمولا هر سیستم را در قالب شبکه ای از زیر سیستم ها و واحدهای عملیاتی مشخص و سپس برای هر واحد عملیاتی خروجی ها را تعیین میکنند ارتباط بین عناصر در شبکه عملیاتی سیستم ها را در قالب دیاگرامی به نام دیاگرام گردش دادها میتوان مشخص نمود . ج-تعیین مشکلات : اگر خروجیهای تعیین شده با استانداردهای مدیریت مطابقت نداشته یا گمتر از میزان پیش بینی شده باشند ویا اینکه خروجی پیش بینی شده در شرح وظایف واحدی ایجاد نشود ، مشکلی در انجام وظیفه آن واحد عملیاتی وجود دارد . بنابر این برای تعیین مشکلات باید معیارهای ارزیابی ، استانداردها و انتظارات مسئولان از عملکرد یک سیستم و واحدهای عملیاتی آن را شناخت . د- یافتن منشاءمشکلات:با تعیین کمبود در خروجی حاصل از عملکرد یک واحد ، مسلما علت یا در عملکرد آن واحد است و یا اینکه اطلاعات به اندازه کافی به موقع به آن واحد نمی رسد . ارئه راه حل : مسلما یک مهندس نرم افزار در حدی نیست که بتوتند برای حل مسائل هر سیستمی راه حل پیشنهاد نماید اما با دانشی که از سیستمهای اطلاعاتی وامکانات سخت افزاری و نرم افزاری دارد ، میتواند در موارد زیر با مدیران ومسئولان جهت تعیین راه حلی برای مشکلات مشخص شده مشاوره کند : - ایجاد یک شبکه اطلاع رسانی کامپیوتری برای تهیه اطلاعات مورد نیاز .- ایجاد یک سیستم اطلاعات مدیریت جهت تهیه گزارشات مورد نیاز . - ایجاد یک سیستم مکانیزه برای پشتیبانی در تصمیم گیریها . - ایجاد یک سیستم مکانیزه مبتنی بر پایگاه دانش به عنوان مشاور در امور . - ایجاد یک سیستم مکانیزه خبره که بتواند مانند یک متخصص در زمینه خاص عمل نماید . ، تحلیل نیازمندیها در سه مرحله انجام می شود. مرحله اول شامل شناخت SSADMاز دیگاه سیستم موجود ، مسائل ، مشکلات و نیازمندیهای کاربر است . در مرحله دوم راه حل ممکن مشخص می شود و با لاخره در مرحله سوم شرح نیازمندیها تهیه و به عنوان گزارش مرحله تحلیل نیازمندیها به مسئولان جهت تصمیم گیری و انتخاب راه حل بهینه ، ارئه میشود . قبل از شناخت نیازها باید مشکل را درک کرد . تشخیص نیاز بدون شناخت سیستم موجود و مسائل آن دشوار است لذا قبل از هر چیز باید سیستم موجود ، اهداف و مسائل آن را شناخت . سپس میتوان نیازها را مشخص نمود به طور خلاصه مراحل شناخت به صورت زیر است : 1) تعیین چهار چوب عملیات شناخت 2) شناخت سیستم موجود 3) تعیین مشکلات و نیازها 4) تعیین منطق عملیات 5) تهیه گزارش شناخت |
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
Business Modeling : موفقیت در یک کسب و کار در اثر عوامل مختلفی بدست می‌آید که یکی از مهمترین و محوری‌ترینآنها طراحی و اجرای یک مدل بهینه کسب و کار در ابتدای کار شرکت است. این مدل که بیانگر الگوی تجاری کردن نوآوری‌ها و ایده‌های تجاری نوآورانه است، در واقع مشخص کننده محدوده سودآوری حاصل از نوآوری خواهد بود. لذا مدل کسب و کار، فرآیند ارتباط دادن فضای نوآوری و تکنولوژی با فضای اقتصادی و کسب و کار است . طبق تعریف، مدل کسب و کار بیانگر این است که شرکت چگونه جایگاه خود را در زنجیره ارزش تولید محصول یا ارائه خدمت تعیین میکند به نحوی که مدل درآمدی پایداری را برای خود ایجاد کند. در هر حال،پارادایم اصلی این است که «شرکت با چه مدلی درآمدزایی می کند؟»
System Modeling : تحليل و مدلسازي سيستمهاي يكي از مراحل پيش‌نياز براي توسعه سيستم است. در اين مرحله انتظارات و نيازمنديهاي ذي‌نفعان سيستم شناسايي شده و گردش كار سيستم در قالب مدلها و نشانه‌هاي استاندارد مستند ميگردد تا از اين رهگذر توسعه‌دهندگان سيستم بتوانند به يك شناخت جامع نسبت به سيستم دست يافته و آنرا منطبق بر نيازهاي كاربران و ذي‌نفعان نهايي، طراحي و ايجاد نمايند.
((( بنابراين هردو نوع مدلسازي لاز م است. )))
|
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| ● اصول مدلسازی: تجربه چهار اصل را برای مدلسازی پیشنهاد میکند: 1) انتخاب مدلهایی که برای ساخت دارای تأثیرات کارآمد و عمیقی بر روی اینکه چگونه میتوان به یک مشکل حمله کرد و چگونه میتوان برای آن راهحل پیدا کرد میباشند. به معنی دیگر مدل خود را خوب انتخاب کنید. یک مدل خوب مشکلات موجود در سرراه پیادهسازی را تصویر میکند و مسیری را که راهی مناسبتر از آن پیدا نمیکنید پیشنهاد میدهد، ولی مدلهای نامناسب شما را به بیراهه راهنمایی خواهند کرد. در تولید نرمافزار مدلهایی را که شما انتخاب میکنید میتوانند تاثیر زیادی بر روی دید شما به مسایل داشته باشند. اگر شما یک سیستمی را بعنوان پیادهساز یک بانک اطلاعاتی درنظر داشته باشید، به احتمال زیاد روی روابط موجودیتی که رفتارشان همانند triggerها و Store Procedureها میباشد تمرکز خواهید کرد. اگر شما سیستمی را بعنوان یک آنالیست مشاهده کنید، مدلها را به احتمال زیاد از دید الگوریتم و جریان دادههایی که بین پروسسها در حال حرکت میباشند بررسی میکنید. پس نتیجه میشود که هر مدل دیدی به سیستم ما میدهد که این دیدها، گوناگون بوده و هزینه و سودهای خاص خود را دارند. 2) هر مدلی بسته به شرایط باید از لایههای گوناگونی بررسی شود. این مسیله هم در دنیای واقعی و هم در صنعت نرمافزار صادق است. گاهی یک مدل سریع و راحت همانند User Interface مشخص میکند که ما نیازمند چه میباشیم. این مسیله در تعیین Platform، شبکه و مسایلی از این قبیل حایز اهمیت میباشد. بهترین مدلها آنهایی هستند که اجازه دهند شما جزییات و وابستگیهای سیستم خود را بشناسید و متوجه شوید که به کدام علت به آنها در سیستم خود نیازمند باشید. در بسیاری از مدلها یک طراح یا کاربر میخواهد بر روی چه چیز متمرکز شود و یک پیادهساز میخواهد بر روی چه طور تمرکز کند، هر دوی اینها میخواهند یک سیستم را در لایهها و زمانهای مختلف تصویر کنند. 3) بهترین مدلها آنهایی هستند که به واقعیت نزدیک و در ارتباط با آن باشند. مدل مناسب باید با دنیای واقعی مرتبط باشد و مشخص کند که در کدام قسمتها دارای ضعف میباشد. در اصل تمامی مدلها حالت ساده شدهای از دنیای واقعی هستند، نکته اصلی در مدل این است که جزییات اصلی و مهم سیستم از قلم انداخته نشده باشد. در نرمافزار، نقطه ضعف در از بین رفتن ارتباط بین مدل آنالیز شده و مدلی که طراحی میشود میباشد. این شکاف بین مدلها باعث ایجاد شکافهای بیشتری در پروژه در زمانهای مختلف خواهد بود. 4) هیچ مدلی به تنهایی کارایی کافی ندارد. هر سیستم بزرگی بهتر است که دارای خط مشیی باشد که به سمت یک مجموعه از مدلهای کوچک با کمترین وابستگی حرکت کند. اگر شما سازنده یک ساختمان باشید، هیچ نقشهای وجود ندارد که تمام جزییات را برای شما مشخص کرده باشد. در حداقل شرایط شما به چندین نقشه مانند برق ساختمان، طبقات، لولهکشی و... نیازمند باشید. شاید جمله سؤال برانگیز، وجود کلمه با کمترین وابستگی در اصل چهارم میباشد. این به معنای داشتن مدلهایی است که میتوانند بطوری مستقل و جداگانه ساخته شده و استفاده شوند. اما هنوز هم بر همدیگر وابستگی دارند. مثلاً در نقشه ساختمان، نقشه برق ساختمان یک نقشه جداگانه و کامل میباشد که میتواند پیادهسازی شود، ولی هنوز بر نقشه بنای ساختمان وابستگی دارد زیرا با تغییر در آن ممکن است نقشه برق نیز دچار تغییر شود. این واقعیت در سیستمهای نرمافزاری شیءگرا صادق است. برای درک معماری چنین سیستمهایی شمانیازمند چندین View بهم مرتبط میباشید که شامل موارد زیر میباشد. - Usecase View (نیازمندیهای سیستم را مشخص کرده و نمایش میدهد). - Design View (پیداکردن مشکلات سیستم و مشخص کردن راهحلهای مربوط به آنها). - Process View (پردازش Threadهای موجود در سیستم را در قالب توزیع شده مدل میکند). - Development View (پیادهسازی و اداره کردن درک فیزیکی سیستم را برعهده دارد). - Deployment View (بر روی مهندسی و تکنولوژی گسترش برنامه متمرکز میباشد). هر کدام از دیدها ممکن است دارای ساختار گوناگونی باشند ولی درمجموع همه آنها نقشه یک سیستم نرمافزاری را نشان میدهند. البته باید توجه داشت که در سیستمهای گوناگون هر کدام از این مدلها ممکن است دارای اهمیت بیشتری نسبت به دیگر مدلها باشند. مثلاً در Graphic User interface(GUI) دیدهای Usecase مهم است. در سیستمهای Realtime دید پردازشی مهم است و در برنامههای تست و Web دید پیادهسازی و گسترش برنامه از اهمیت بالایی برخوردار است. امروزه یک سازمان نرمافزاری موفق سازمانی است که بتواند بسادگی نرمافزارهایی را تولید کند که نیازهای کاربران در آن دیده شده باشد. چنین سازمانی که بتواند چنین نرمافزاری را با روشها و ابزار مؤثر و در زمان مناسب پیادهسازی کند، میتواند در امر تجارت موفق باشد. محصول اولیه یک تیم تولید نرمافزار، بهینه نمیباشد و شعار نمیدهد بلکه مهم است که نرمافزاری را پیادهسازی کرده باشد که نیازهای کاربران و تجارت را برآورده سازد. بقیه موارد حالت ثانویه به حساب میآیند. نکته مهمی در این شعار وجود دارد. متأسفانه بسیاری از سازمانهای نرمافزاری درگیر حالت ثانویه میباشند. برای پیادهسازی نرمافزاری که اهداف موردنظر را برآورده سازد، شما باید کاربران را ملاقات کنید تا نیازهای واقعی سیستم شما بدست آید. میتوان گفت برای اینکه شما در نهایت بتوانید نرمافزاری با کیفیت بالا به وجود آورید، باید دارای افراد و ابزاری مناسب به همراه هدف مشخص و واضحی باشید. مدل کردن، قسمت مرکزی تمامی فعالیتهایی است که پیادهسازان نرمافزاری را به سمت تولید یک محصول مناسب راهنمایی میکند. ما سیستمها را مدل میکنیم برای اینکه رفتارها و ساختارهایی را که در سیستم خود میخواهیم بصورت کتبی داشته باشیم، ما مدل میکنیم تا بتوانیم معماری سیستم خود را کنترل کنیم و بتوانیم سیستمی را که در حال ساختن آن میباشیم بهتر درک کنیم، امکان Reuse را در سیستم داشته باشیم و همچنین ریسکهای پروژه را مدیریت کنیم. بسیاری از سازمانهای نرمافزاری شروع به انجام کارهای بزرگ میکنند، ولی مشکل اصلی این است که آنها همانند ساختن لانه برای پرندهها عمل میکنند (برای ساختن لانه پرنده میتوان با تعدادی تخته و میخ و بدون نیاز به نقشه اقدام به ساخت لانه کرد). اگر شما واقعاً میخواهید که نرمافزاری را بدون هدف و در کمترین زمان ممکن تولید کنید مشکلات این کار فقط نوشتن خود برنامه میباشد، ولی در واقع هدف اصلی ایجاد یک نرمافزار صحیح میباشد و پیادهسازی یک نرمافزار کارا وابسته است بر ابزار، فعالیتها و معماری که آن نرمافزاری استفاده میکند. بسیاری مواقع پروژهها بصورت کوچک شروع میشوند ولی پس از مدتی به پروژههای بزرگ تبدیل میشوند، بخاطر آنکه آنها موفقیت کاری خودشان را در این راه قربانی میکنند. |
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
ابزارها واستانداردهای فنی مدل سازی فرآیند Business Process modeling: BPMN: استاندارد ترسیم فرآیندها*XPDL: استانداردی برای تبادل توصیف فرآیندها بین BPMSهای مختلف BPML : استاندارد مدلسازی و توصیف فرآیندها BPEL : زیان استاندارد توصیف فرایندها*BPEL۴WS: توسعه‌ای از BPML برای کار با سرویسهای وب Wf - XML: استانداردی برای یکپارچه‌سازی و اتصال WFها مدلهای ساخت یافته که در حال حاضر کمتر در تولید سیستم ها مورد استفاده قرار می گیرند یا روشی تحت عنوان SSADM(Structured System Analysis and Design) ساخته می شود. : مدلهای تحلیل و طراحی شیءگرا در حال حاضر غالباً توسط زبانهای مدلسازی UML ابزار Unified Modeling Language ساخته می شود
|
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
يك عامل بسيار مهم و تعيين كننده در موفقيت سيستمهاي جامع نرم افزاري، انتخاب نوع متدولوژي مناسب است. از مجموعه متدولوژيهاي بر اساس تفكر شي گرا RUP
اصول اساسی RUP ü حمله سریع و مداوم به ریسکهای اصلی...در غیر این صورت آنها به شما حمله خواهند کرد. ü تضمین کنید که محصول باارزشی به مشتری تحویل می دهید. ü روی نرم افزار اجرایی متمرکز بمانید. ü تغییرات را هر چه زودتر در پروژه بگنجانید. ü سیستم را به صورت مولفه ای بسازید. ü در قالب یک تیم با هم کار کنید. ü کیفیت را به عنوان یک اصل قرار دهید نه یک فرع. این روش علاوه بر ساماندهي به فرايند توليد نرم افزار از دو بعد زمان و کيفيت، به لحاظ برخورداري از انعطاف پذيري بالا در صورت کاربرد و پياده سازي صحيح مي تواند سبب تسريع فرايند توليد و توسعه نرم افزار و تأمين کيفيت مورد نظر در نرم افزار گردد.RUP اگر چه بسيار وسيعو براي پروژه هاي بزرگ تدوين شده است، اما مي توان با درنظر گرفتن فاكتورهايي مانند اندازه پروژه و رسمي بودن آن ، آنچه را كه با پروژه تناسب دارد، انتخاب كرد و به مرحله اجرا درآورد. در ميان 10 فرآورده مهم اين روش ، تعدادي در اكثر پروژه قابل استفاده هستند و كاربرد تعدادي اختياري ست كه مدير و تيم پروژه مي بايد با توجه به پروژه ، در مورد لزوم كاربرد آنها تصميم گيري كند.
|
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
|
از مجموعه متدولوژيهاي بر اساس تفكر ساخت يافته Oracle CDM ، SSADM
|
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
مدل سازی کلان کسب وکار درجه اهميت مدل سازي كسب و كار و سيستمي رامشخص مي كند ا مروزه دیدگاه فرآیندگرا در ساختار سازمان ها و نوسازی روش هایکاری رواج بسیاری دارد. این رویکرد با رواج بازمهندسی فرآیندهای کسب وکار (BPR)( ۱ ) و استفاده از بسته های نرم افزاری برنامه ریزی منابع سازمانی (ERP) ( ۲ ) اهمیت بسیاری یافته است. مدل سازی کلان فرآیندها حاکی از مدلسازی فرآیندهای کلیدی در یک سازمان است و درجه اهيمت مدل سازي كسب وكار و سيستمي رامشخص مي كند یعنی فرآیندهای تولیدی یا خدماتی با یک دیدگاه کل نگر برای درنظر گرفتن تعاملات بین آنها و اثری که در مجموع بر معیارهای کلیدی اثربخشی درسازمان می گذارند. تجزیه سلسله مراتبی، که امکان تعیین فرآیندها و فعالیت ها را بهصورت مفصل تر فراهم می آورد، مفهومی مفید در مدل سازی فرآیندهای کسب وکار است . مدل سازی کلان فرآیندها یک گام مفید اولیه در این روش است. هدفاز مدل سازی سازمان می تواند ارزیابی عملکرد کلی سیستم از نظر تعادل بین گروه هایکاری، مسائل مربوط به تدارکات و تامین مواد و نگاه به تصمیمات کلانی که برایکارخانه گرفته می شود، باشد . اهمیت مدل سازی کلان کسب وکار بسیاری از سازمان ها فراتر از چهاردیواری سازمان خود نگاه کردهو تلاش کرده اند مشتریان و تامین کنندگان را در زنجیره ارزش و سیستم های خود واردسازند . تعاملات بین فرآیندها در یک سازمان وذی نفعان بیرونی مانند مشتریان و تامین کنندگان می تواند به صورت بسیار بهتری بامدل سازی کلان کسب وکار نمایش داده شود. با استفاده از بینش هایی که از مدل ها کسبمی شود BPR را می توان به گونه ای انجام داد که دیدگاه های مشتریان و قابلیت هایسیستم پشتیبان به روشنی همزمان با انجام کار در نظر گرفته شوند، نه اینکه پس ازانجام بازمهندسی به آنها اندیشه شود . مدل سازی کلان کسب وکار می تواند بخشی از یک رویکرد ازبالابهپایین یا از پایین به بالا در مدل سازی کسب وکار باشد. در رویکرد بالابه پایین،مدل سازی کلان بخشی از فرآیندی است که تعریف مدل را بهبود می دهد. تا زمانی که یکفرآیند، فعالیت یا یک بخش کارکردی به صورت عناصری تجزیه نشود که رفتار آنها رابتوان به صورت مفصل و دقیق تعریف کرد، در مورد میزان دقتی که در نمایش آن در مدلبه کار گرفته شده است تشکیک وجود خواهد داشت. تحلیل حساسیت می تواند روشن کند کهکدام یک از بخش ها را باید به صورتی مفصل تر تجزیه کرد تا قابلیت اعتماد بر نتایجمدل سازی تضمین شود؛ اما در شیوه از پایین به بالا، خرده سیستم هایی را که به صورتمفصل مدل سازی شده و مورد اعتبارسنجی قرار گرفته اند، می توان برای تشکیل یک مدلبزرگ تر تجمیع کرد . فعالیت های کلیدی در تعیین یک فرآیند برای بازمهندسی به قرارزیرند برشماری فرآیندهای عمده تعیین مرز و محدوده فرآیندها ارزیابی اهمیت استراتژیک هر کدام از فرآیندها قضاوت کلی درباره سلامت هر کدام از فرآیندها ارتقای کیفیت فرهنگ و موارد سیاستی مربوط به هر کدام ازفرآیندها |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| تفاوت اجزا و تشکيلات در BPM چيست؟ BPM شامل انتظامات مختلفي است که به منظور استفاده در طول سطوح و نواحي مختلف درون سازمان واقع ميشود. بعضي از اين انتظامات شامل : مدل فرايند تجاري . فرايند ( عموماً در فرمتهاي ترسيم شده ) تعريف ميشود. از آنجا که شفافيت فرايندهاي مدلسازي شده براي تمامي انتظامات بعدي BPM مورد نياز است ، مدلسازي فرايند اغلب بعنوان شروع هدف از BPM تداعي ميشود. تعريف با استفاده از مدل ساز فرايند ( نبايد با ويراستارهايي از قبيل Visio و يا PowerPoint اشتباه گرفته شود ) . نتيجه مدل متشکل از اهدافی است که قادر است تا با موتورهای BPM مرتبط گردد . آن ترکيبي از دياگرامهاي متفاوت ( براي نمايش ابعاد سازمان ) است، و مدل در ظرف ساخت يافته ذخيره سازي ميشود. مستندسازي فرايند تجاري. مسئول فرايند – ارتفاي مستند سازي دياگرامهاي فرايند را توسط فراهم آوري درطول ترسيمات ، و اين که براي گام بعدي و نسخ آن چه بايد انجام داد را تکميل ميکند. همچنين به آن مستند سازي وسيع توسط فراهم آوري چگونگي انجام وظايف تجاري به طراحي مدل نيز اصافه ميگردد. ايتمهايي از قبيل ساختار کاري، روندهاي عملياتي استاندارد ، الگوهاي پيشرفته ، ترکيبات آموزشي و غيره به دیاگرامها براي ارتقاي خلق يک فرايند مستند سازي اضافه ميگردند. تاييديه فرايند تجاري. توانمندي فرايند به توافق توام با استانداردهاي مستندسازي صنعتي از قبيل ISO ويا از طریق يک مدخل فرايند دروني مراقبت ميگردد. آن تثبيت ميکند که فرايندها در يک رويه متناسب قبل ازگسترش درونيشان تصويب و يا تاييد شده اند. همکاري فرايند تجاري. گسترش فرايند ( اشاعه شبکه دروني يا بيروني ) ازيک طرف و فراهم آوري کاربران با توانايي بکارگيري چگونگي و شناسايي فرايند به منظور ارتقاء بهره وری از راه کاربر و همکاري وظايف از طرف ديگرکاملاً ملموس میباشد. انتظامات BPM همکاري وسيع دانش مديريت را (KM) نه تنها در ساخت مستندات و اماده سازي در دسترس فراينداهاي مورد تاييد براي همه کارمندان و شرکا راهنمايي ميکند بلکه همچنين عمليات همکاري کارمندان را که آنها را در مديريت پروژه ها ، وظايف ، يا تبادلات در يک رويکردي از کار تيمي است فراهم ميسازد. اجابت فرايند تجاري. تاسيس آماده سازي فرايندها براي اجابت با تنظيمات دروني و بيروني از قبيل (Sarbanes-Oxley [SOX]). اجابت فرايندهاي تاييد شده براي دستيابي به مقرر نمودن تاييديه ، مميزي و يا هردو آن بکار ميرود. بهينه سازي فرايند تجاري. مسئوليت براي بهبود فرايند مستمر (CPI) شامل ابزارهايي براي تعيين اجراي فرايند واقعي برخلاف قوائد باطني يا نمونه هاي صنعتي است. توانايي تحليل کمي يکپارچه ، به منظور شناسايي تنگناها و تخمين فرصتهاي حفظ هزينه و زمان حاصل کار مورد استفاده واقع ميگردد. اين اغلب شامل شبيه سازي ماشيني براي اجراي تحليلهاي چه ميشود – اگر براي تعيين رويه هاي فرايند دريک ورش از قبل پيش بيني شده. فرآيند تجاري خودکار. مسئوليت يکپارچگي ميان کاربران فرايندها و تقاضاهاي مرتبط دروصايف فرايندي سيستم خودکار حاصل ميايد . هدايت از طريق ماشيي مديريت خودکار ، اطلاعات فرايندي BPM ميتواند براي مسيريابي واجراي تبادلات خودکار مورد استفاده قرارگيرد که شامل وظيفه اجرايي راه اندازي شده توسط وقايع قبلي ، استنتاج وظايف برنامه ريزي و آگاه سازي کاربر، پايش زمان واقعي از وظايف اجرايي و ديگر موارد اجرايي از قبل تعيين شده باشد . چرا بايد از BPM بهره برد ؟ سازمانها به منظور ارتقاء کارايي مرکز عملياتي فعاليتهاي خود از سيستمهاي BPM استفاده ميکنند . BPM خصوصاً تبادلات ميان سيستمها ، فرايندهاي تجاري ، و تبادلات انساني را تعديل ميکند . نتايج مورد انتظار شامل صرفه جويي اقتصادي . توسط خودکار سازي مسير فرايندها و وظايف کارمندان ، دوري جستن از فعاليتهاي بي ارزش ، اضافه نمودن فعاليتهايي از قبيل مسيريابي تصميمات ، انتقال داده ها يا فرمها و غيره و فراهم آوري امکاناتي براي کاربران فراخور ليست وظايف . صرفه جويي در وقت توسط تغيرر فرايندهاي تجاري در هر تکنولوژ، صلاحديدها ويا احتياجات رقابتي . با يکپارچگي تنگاتنگ تعرف فرايندها و تقاضاهاي تضمين شده ، تغيير در تعاريف ميتواند بطور مجازي و باسرعت بالا مراوده و گسترش يابد . ارزش افزوده ، ازطريق بازنمودن محدوده اي از عملياتها که ميتواند دريک BPM درست مورد نظر شرکت بکارگيري شود . ارزشها ميتوانند در چندين محدوده متفاوت ازتحليلهاي کمي فرايندها و بهينه سازي ، تاييديه کيفي ، ازقبيل ISO و خلق و انتشار رويه هاي مورد نياز، افزوده گردند . محدوده ديگجر تقبل مديريت است که بر همه سازمان اعمال ميگردد. با بکارگيري BPM شرکتها قادرند تا فرايندهاي تجاري عملياتيي که در بسياري از سيستمها مورد استفاده واقع شده و افراد و شرکا در آن طبقه بندي شده اند را هماهنگ کنند و بکاربرند. منفعت سيستمهاي BPM واقعيت مشتريان است . مشتريان بسرعت قادرند تا محصولات و اطاعات مورد نظر را دريافت کنند و نتيجه آن ارتقاء سطح رضايت مشتريان است . و معناي آن سود بيشتر شرکت است . در ارتباط با احتياجات سازمانها ، طبقات مختلفي از ارائه دهندگان BPM براي هر حالتي ميتواند موجود باشد. اگرتمرکز قويي بر حمايت قوانين تجاري پيچيده براي فعاليتهاي مرکز گراي انساني ، شايد بهترين راه حل ، ارائه BPM محض باشد . در جايي که تمرکز بر تقاضاهاي منظفي يکپارچه موجود است ، تقاضاي ارائه دهند BPM ميتواند بهترين راه حل را ارائه دهد . در زير ميتوانيد طبقه بندي متفاوت کلاسهاي ارائه دهنگان را مشاهد نماييد . انواع ارائه دهنگان مزيت راه حلهاي بالقوه يکپارچگي تقاضا يکپارچگي فرايندهاي تجاري با يک گستردگي از سيستمهاي تقاضاي ناهمگن پلتفرمهاي تقاضا يکپارچگي فرايندهاي تجاري و تلاش در جهت پيشرفت تقاضاي سنتي تقاضاهاي تاسيس شرکت يکپارچگي فرايندهاي تجاري با محيطي که تمرکز بر تکنولوژي ارائه دهنده تاسيس شرکت داشته باشد ارائه دهندگان رضايتمندي محض فرايندهاي تجاري که هردو مردم و سيستمها ، احتياجات قوانين تجاري پيچيده و يا تکنولوژيهاي يکپارچه چندگانه را پوشش ميدهد . مديريت رضايت مندي تاسيس شرکت مديريت فرايندهاي تجاري متمرکز برمستندات که محتويات غيرساختاري را بازنگري و تصويب ميکند . نقش عرضه کنندگان به بازار تعداد چندي از ارائه دهنگان خدمات BPM در بازار موجود ميباشند . در ميان ارائه دهنگان شرکتهاي Chordiant, SAP, و Oracle موجودند. پلتفرم ارائه دهنگان شامل IBM و BEA و ماکروسافت است درحالي که SeeBeyond, Tibco, و Vitriaتمرکز بر بخشهاي يکپارچه از تقاضا را دارند. درميان ارائه دهنگان رضايتمندي محض ازBPM ، FileNet, Lombardi و DynaFlow Modeling & Workflow Solution موجود ميباشند. TEC اخيراً با DynaFlow در باره BPM صحبت نموده . اين شرکت در سال 1997 با شعباتي در امريکای شمالي و اروپا تاسيس گشته است . DynaFlow’s flagship BPM solution, EZ-Process پوشش دهندگان اصلي BPM ميباشند و آن براي يکپارچگي وسازگاري با SSA Baan IV و ERP در سال 2000 ، EZ-Process درتقاضاهاي SSA Baan ERP , CRM و درخواستهاي B2B از قبيل Fujitsu, Siemens, MD Robotics, and Solar Turbines/Caterpillar بکارگيري شده است. هنگامي که براي BPM درخواستي ميگردد ، Pierre Beaulieu, President of DynaFlow از DynaFlow اضهار دارد که آن به يک عنصر کليدي براي فراهم آوري سازمانها با همان زيرکي و توانايي و سازگاریی که آنها در موفقيت اوايل قرن بيستم بازار جهاني نياز داشته اند ، تبدیل شده است. BPMقصد دارد تا کمپانیها استانداردهای تنظیمی را برای خود تعیین کنند و بيشتر از آن چون BPM دوست دارد تا بودجه را کاهش دهد بطوري که آن مرکزيت بر روشهاي بکارگيري ورودي سرمايه اي از قبيل شناسايي و چگونگي فرايند توليد و تعديل کارمندان دارد بنابراین مديران سيستم بايد وسعت استفاده از آن را درک کنند. به منظور چالشهاي تجارت BPM ، هشت مدل DynaFlow و همراهان EZ-Process توافق بر الزامات کليدي BPM نموده اند . زيرساخت شبکه وب آنها قادر است تا گسترش وسيعي از مشارکت که براي دانش مديريت از BPM مبهم است را يکسان کند. راه حل آن قابل سنجش و قابل عرضه براي بدنه کاريي است که براي درخواستها و سيستمهاي مخنتلفي در فرايندهاي وظيفه اي يکپارچه شده است. همچنين فرايند خودکار ( گردش کار ) منودرخواستهاي سنتي را با ليست کاربري On Line که پيگيري پوياي تبادلات ميان فعاليتها را فراهم مياورد ، جایگزین میسازد. بعضي از مدلهاي همراهان EZ-Process ، EZ-Modeler ميباشند . يک فرايند مدلسازي مدل ، پايه اي بر Petri-nets دارد . EZ-Book ، يک سيستم دانش مديريتي وسيع ، EZ-Publisher ، که شامل سيمايي از همکاري و سردر فرایند بوده و EZ-Workflowکه فرايند خودکار و يکپارچه ميباشد. روند تجارت در آينده چه خواهد شد ؟ تجارت متناسب با آينده اي که در پيش رو داريم ، درحال تغییر است . نتنها فروشندگان نمايش محض بر افزايش سهام فروششان کار ميکنند ، فروشنگان پلتفرم و ارائه دهنگان تاسيس شرکتها بيشتر تمايل دارند تا در آينده سهميه خوبي از BPM را ارائه دهند . pie سهامي برابر با همه ارائه دهنگان در اين بخش نخواهد داشت وامکان رشد سريع ارائه دهنگان و فراهم کنندگان کوچکتر ميتواند سناريوي درستي باشد . بطوري که فروشنگان کوچکتر فروششان را در اين بخش گسترش ميدهند ، آنها ميتوانند مشارکت بيشتري با ارائه دهنگان بزرگتر داشته باشند . آنها قادر خواهند بود تا راه حلهاي خود را توانمند سازند خصوصاً در ناحيه اي از رويارويي با نيازهاي تجاري از سازمانها و احتياجات عمودي صنعتي شان براي تکميل در اين روند روبه پيشرفت در فروش . بنابراين زماني که يک سازماني در ارائه دهنگان راه حل BPM جستجو ميکند ، آنها بايد احتياجاتشان را به خوبي تعريف کرده باشند و خصوصاً زماني که آنها براي وظايف ويژه سازماني خود جستجو ميکنند ، فروشندگان خرد پيشنهاد ميگردند. نتيجه : بنظر ميرسد که فروش به سطح تکاملي خود رسيده باشد بطوري که فروشندگان درحال حاضر نگهداري وظايف را که سبب جلوگيري از هموار سازي و گردش وسيعي ازنقطه سربه سر تاسيس فرايندهاي تجاري ميشود را منسوخ قلمداد ميکنند. فروشندگان هردو تبادلات و سيستمهاي اطلاعات و مديريت اسناد را به يکديگر متصل ميکنند بطوري که در سازمانها سعي برآن است تا فرايندهاي تجاري ناتمامشان را هماهنگ کرده و از اتلاف زمان و هزينه جلوگيري نموده و ارزش افزوده را به آن ميافزايند. بطوري که در اين مقاله بحث گرديد ، در عمليات متفاوتي در طعم و بوي فروش در جريان است . درواقع آن يک برتري جويي است که سازمانها به دقت احتياجات وظيفه اي و الزامات اينده خود را ارزيابي کرده و اين را بر خلاف راه حلهاي موجود مقايسه ميکنند. هرچند چالش مشتريان در طول رشد سرمايه محصولات تقاضا شده افزايش ميابد و بايد مطمئن بود که آنها يک تصميم درستي از اين که چه نوع فروشنده اي از BPM نيازشان را به بهترين نحو ممکن ايجاد خواهد کرد . |
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
|
تحليل و مدلسازي سيستمهاي اطلاعاتي يكي از مراحل پيش‌نياز براي توسعه سيستم است. در اين مرحله انتظارات و نيازمنديهاي ذي‌نفعان سيستم شناسايي شده و گردش كار سيستم در قالب مدلها و نشانه‌هاي استاندارد مستند ميگردد تا از اين رهگذر توسعه‌دهندگان سيستم بتوانند به يك شناخت جامع نسبت به سيستم دست يافته و آنرا منطبق بر نيازهاي كاربران و ذي‌نفعان نهايي، طراحي و ايجاد نمايند. به منظور استاندارد نمودن ابزارها و روشهاي مدلسازي و مستندسازي سيستمهاي اطلاعاتي، مجموعه‌اي از مدلها و متدولوژي‌ها ارائه شده‌اند كه اين مدلها و متدولوژي‌ها به عنوان زبان مشترك تحليل‌گران سيستم و برنامه‌نويسان به شمار مي‌آيند. در قالب اين مدلها و متدولوژي‌ها مجموعه استانداردي از مستندات تهيه شده تا برنامه‌نويسان بتوانند با بهره‌گيري از اين مستندات نيازهاي كاربران را در قالب نرم‌افزارهاي كاربردي پاسخگو باشند. يكي از اين متدلوژي‌ها كه به صورت گسترده‌اي مورد استفاده طراحان و توليدكنندگان سيستمهاي اطلاعاتي قرار ميگيرد، متدولوژي RUP است كه با رويكرد شي‌گرا ارائه شده است. اين متدولوژي از نشانه‌ها، علائم و مدلهاي زبان مدلسازي UML براي مدلسازي سيستمهاي اطلاعاتي استفاده مي‌نمايد. اين متدولوژي در مراحل چندگانه خود مستندات و خروجي‌هاي مختلفي را ارائه مي‌نمايد كه ميتواند توسط برنامه‌نويسان و توسعه‌دهندگان سيستم مورد استفاده قرار گيرد. اين متدولوژي يكي از متدولوژيهاي شي‌گرا است كه براساس مدل چرخشي توسعه يافته است. قابليت‌هاي اين متدولوژي در توسعه سيستمهاي منطبق بر نيازهاي كاربران، بهره‌گيري از زبان مدلسازي UML و ايجاد ابزارهاي نرم‌افزاري مدلسازي مانند Rational Rose، اين متدولوژي را به يك روش متداول توسعه سيستمهاي اطلاعاتي تبديل نموده است.  RUP مراحل متدولوژي
هريك از اين مراحل طي مجموعه‌اي از فعاليتها (گردش كار) صورت ميگيرد. فعاليتهاي اصلي اين متدولوژي عبارتند از:
فعاليتهاي مديريت تغيير و پيكره‌بندي و مديريت پروژه نيز فعاليتهاي پشتيباني اين متدلوژي هستند. فعاليتهاي اصلي و پشتيباني اين متدلوژي در قالب چهار مرحله اصلي صورت ميگيرد. به اين صورت كه در هر مرحله بخشي از فعاليتهاي پروژه تكميل ميشود. در مراحل ابتدايي بيشتر اقدامات و فعاليتها بر شناخت نيازها و وضعيت موجود تمركز مي‌يابد. در مراحل مياني فعاليتها به طراحي و توسعه سيستم معطوف ميشود و در بخش انتهايي نيز بخش عمده‌اي از فعاليتها حول محور پياده‌سازي و تحويل سيستم صورت ميگيرد. با اين تفاسير چهار مرحله اصلي اين متدولوژي عبارتند از:
توسعه سيستمهاي اطلاعاتي در متدولوژي RUP به صورت تكاملي بوده و از مدل چرخشي يا حلزوني تبعيت مي‌نمايد. در اين مدل توسعه سيستم به صورت تدريجي طي مراحل مختلفي صورت مي‌پذيرد كه سيستم در هر مرحله نسبت به مرحله قبل كاملتر شده تا در نهايت در مرحله انتهايي سيستم به صورت كامل توسعه يابد.
مستندات و محصولات ضروري RUP عبارت از موارد زير ميباشند:
|
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
|
مدل کردن فرآيندهای کسب و کار (و یا فرآيندهای سازمانی) یکی از ابتدایی ترین گام های حرکت به سمت بهینه سازی آنهاست. هدف از مدل کردن فرآيندها به نوعی مستندسازیروند انجام اموری است که به هر شکل سازمان در آن دخیل است. وجود یک زبان مشترک و استاندارد به منظور مدل کردن فرآيندها کمک می کند تا این مستندات در شرایط زمانی و مکانی مختلف کارایی خود را از دست ندهند. یکی دیگر از مهمترین مزایای مدل کردن فرآيند های سازمانی حفظ پیوستگی در تصمیم گیری های سازمان است. با وجود مدل مستند کسب و کار، پس از تغییرات احتمالی در تیم مدیریت، سازمان دچار سردرگمی و احیاناً تغییرات عمده نمی شود. بلکه تیم مدیریت جدید جهت بهبود مدل قبلی تلاش خواهند کرد و اینگونه است که پیوستگی موفقیت و ثبات یک سازمان حتی پس از مرگ شخص اول آن ادامه دار می ماند. سطوح متفاوتی برای مدل سازی فرآيندها وجود دارد: 1. نقشه فرآيند )فلوچارت های ساده از فعالیتها( 2. توصیف فرآيند )فلوچارت به همراه اطلاعات اضافه اما نه به اندازه ای کامل که عملکرد آن را به طور کامل توصیف کند( 3. مدل های فرآيند )فلوچارت به همراه اطلاعات اضافه کامل که فرآيند بتواند تجریه و تحلیل، شبیه سازی و یا اجراشود( 4. نشانه گذاريِ مدل سازي فرآيند های كسب و کار که هر یک از سطوح نام برده در فوق را پوشش می دهد. برخی از مهمترین مزایای استاندارد سازی علائم مورد استفاده در مدل سازی فرآيند به شرح زیر است: افراد درگیر در تیم مدلسازی فرآيند: · کارشناس کسب و کار: کسی که دانش زیادی درباره فرآيند دارد. · صاحب فرآيند: فردی که مسئول اجرای کل فرآيند است و اصلاحات فرآيند را تایید می کند. · مدیر یا میانجی: مسئول قرار ملاقات ها، برای پرسیدن سوال جهت راهنمایی برای گرفتن تصمیم درست است · کارشناس مدل سازی: مسئول طراحی مدل فرآيند است چگونه مدل سازی کنیم؟ 1. بالا به پایین (Top-Down): 2. پایین به بالا (Bottom-Up): 3. داخل به خارج (Inside-Out): نکته: رویکرد داخل-خارج معمولاً عملی ترین رویکرد برای مدل سازی فرآيند است. نشانه گذاريِ مدل سازي فرآيند های كسب و کار ابزار اصلی در تکنولوژی مدیریت فرآيندهای کسب و کار می باشد. در واقع می توان گفت مزیت اصلی استفاده از تکنولوژی مدیریت فرآيندهای کسب و کار، وجود زبان استانداردی به نام نشانه گذاريِ مدل سازي فرآيند های كسب و کار می باشد. ویژگی اصلی نشانه گذاريِ مدل سازي فرآيند های كسب و کار، قابلیت تبدیل آن به زبانهایی است که قابل درک توسط سیستمهای نرم افزاری می باشد. نشانه گذاريِ مدل سازي فرآيند های كسب و کار، نموداری تحت عنوان ( نمودار فرآيند كسب و كارBusiness Process Diagram-BPD ) فراهم نموده که به منظور استفاده افراد در طراحی و مدیریت فرآيند های کسب و کار طرح ریزی شده است. عملاً نمودار فرآيند كسب و كار شبکه ای از اشیاء گرافیکی است که فعالیت ها، کنترلهای جریان و چگونگی ترتیب اجرای فعالیت ها را نمایش می دهد. |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| Business Model: شیوه ای که شرکت، بنگاه یا سازمان برای تولید سود و سرپا نگه داشتن خود انتخاب می کند. مدل کسبوکار بیان می کند که چگونه سازمان برای تولید محصول یا ارائه خدمت ایجاد ارزش افزوده میکند. (Value Chain) تعریف مدل کسب و کار غالبا با دشواری همراه است زیرا در زمینه های متفاوت کسب و کار معانی متفاوتی از آن برداشت می شود و ارائه یک تعریف یکسان در همه کسب و کارها مقدور نیست.این نقصان در تعریف مدل های نوین کسب و کار الکترونیک بیش از سایر حوزه ها احساس می شود. مدل کسب و کار (shogian، 2008) به بیان ساده عبارت از متدی است که شرکت در فعالیتهای تجاری در پیش گرفته و با کسب درآمد ثبات خود را حفظ می نماید. در این مدل با توجه به منابع در دسترس و نیاز مشتری، پیشنهادی برای عرضه ارزش مورد نظر مشتری ارائه شده و منافع و درآمد نصیب شرکت می سازد. به تعبیری دیگر ;مدل کسب و کار چگونگی کسب درآمد توسط بنگاه را با مشخص کردن جایگاه آن در زنجیره ارزش مشتری تشریح می کند. System Modeling:مدل سیستمی مجموعه ای از تعاملات به هم مرتبط در یک سیستم است که این تعاملات را به شیوه های مختلف به منظور در نظر گرفتن تأثیری که تغییرات طراحی و کارکردی در یک بخش روی بخش های دیگر سیستم می گذارد، انجام می دهد. SSADM چيست؟ شايد اين نام را در سايتهاي اينترنتي و مجلات مديريت كامپيوتري ديده باشيد. Structured Systems Analysis Design Method متدلوژي آناليز و طراحي ساخت يافته سيستم بطور كلي طراحي يك سيستم از مراحل زير تشكيل شده است: 1- تعريف مسئله: نيازهاي فعلي و آينده ي سيستم و كاربران 2- امكان سنجي: بررسي امكان و يا عدم امكان پاسخ به نيازهاي تعيين شده 3- تجزيه و تحليل سيستم: بررسي و تحليل جزئيات نيازهاي كاربران در سيستم موجود 4- طراحي سيستم پيشنهادي: طراحي سيستم مورد نياز جهت رفع نيازها 5- طراحي منطقي: حذف دوباره كاريها، رفع ايرادات منطقي و تعيين وظايف هر مرحله از كاركرد 6- طراحي فيزيكي: طراحي و ايجاد بانك اطلاعاتي و مشخصات و چهارچوب برنامه ها 7- توسعه و برنامه سازي: نوشتن برنامه ها با توجه به شرح و استانداردهاي لازم 8- پياده سازي: اجرا، راه اندازي و عملياتي كردن سيستم 9- تست و آزمايش: تست كامل تمامي سيستم توسط كاربران و طراحان 10- بررسي نتايج سيستم: بررسي موفقيت سيستم در دستيابي به اهداف 11- نگهداري: رفع ايرادات جزئي و اشتباهات SSADM مجموعه به هم پيوسته از راهنماها و روشها و استانداردهاست كه مراحل طراحي سيستم را از بخش امكان سنجي تا طراحي فيزيكي در بر مي گيرد. ( با كمك ابزارها و متدهاي SSADM مي توان سيستمي را به بهينه ترين شكل ممكن طراحي نمود و برخي مزاياي آن عبارتند از: • كنترل بهتر پروژه • تحويل به موقع كار • ارائه ي كار منطبق با نيازهاي كاربر و اهداف سازمان • نهايت استفاده از امكانات • انعطاف پذيري • افزايش بهره وري • عدم وابستگي برنامه توليدي به نرم افزار يا سخت افزار خاص • امكان استفاده از ابزارهاي نرم افزاري (Case Tools) جهت توسعه سيستم پس بطور كلي SSADM مجموعه روشهايي است براي بهره وري بيشتر در توليد سيستم. RUP چیست ؟ معماری و ساختار كلی RUP فرایند انجام یک پروژه تعریف میکند که چه کسی، چه کاری را در چه هنگام و چگونه برای رسیدن به هدف (انجام پروژه) انجام میدهد. در مهندسی نرمافزار، هدف ساختن یک محصول نرمافزاری و یا بهبود یک نمونه‌ی موجود است. هدف از تعیین فرایند، تضمین کیفیت نرمافزار، برآورده شدن نیازهای کاربر و قابل تخمین بودن زمان و هزینه‌ی تولید میباشد. علاوه بر این، تعیین فرایند، روندی جهت تحویل مصنوعات دوران تولید نرمافزار به کارفرما و ناظر پروژه ارائه میدهد تا از این طریق اطمینان حاصل کنند که پروژه روند منطقی خود را طی میکند و نظارت درست بر انجام پروژه ممکن است و از سوی دیگر، معیاری برای ارزیابی پروژه انجام شده میباشد. تا كنون متدولوژی‌های مختلفی برای فرآیند تولید نرمافزار ارائه شده‌اند كه یكی از مشهورترین آنها RUP است. RUP ، متدولوژی ارائه شده توسط شرکت Rational ، پرکاربردترین فرآیند تولید و توسعه نرم افزاری در دنیای کنونی است و به عنوان یک استاندارد صنعتی بالفعل در دنیای IT پذیرفته شده است. به گزارش رویتر در سال 2001 میلادی بیش از ششصد هزار شرکت تولید کننده نرم افزار، از ابزارهای شرکت Rational استفاده می کرده‌اند که این تعداد کماکان هم در حال افزایش است. این متدولوژی، برای انواع پروژههای نرمافزاری در دامنه‌های مختلف ( مانند سیستمهای اطلاعاتی، سیستمهای صنعتی، سیستمهای بلادرنگ، سیستمهای تعبیه شده، ارتباطات راه دور، سیستمهای نظامی و ...) و در اندازه‌های متفاوت، از پروژههای بسیار کوچک (یک نفر در یک هفته) تا پروژههای بسیار بزرگ (چند صد نفر تولید کننده با پراکندگی جغرافیایی)، کاربرد دارد. مزیت بزرگ این متدولوژی، استفاده از روش تکرار در تولید و مدیریت تولید نرمافزار است که این امر، امکان تولید مبتنی بر کاهش ریسک و مواجه با مشکلات اصلی در ابتدای کار و در نتیجه احتمال موفقیت بیشتر را فراهم میکند. از محاسن دیگر این متدولوژی مبنا قرار دادن نرمافزار و تولید یک معماری پایدار در ابتدای کار است، که در نتیجه امکان کشف مشکلات عمده ساختاری، تست و مجتمع سازی ممتد را از ابتدای کار فراهم میکند. از دیگر مزایای این روش این است که افراد تیم همزمان با پیشرفت پروژه، مطالب جدیدی فرا می‌گیرند و کیفیت فرآیند تولید نیز به طور مرتب افزایش می‌یابد. همانطور كه در شكل بالا مشاهده میشود، RUP دارای دو بعد است: 1. محور افقی نشان دهنده‌ی زمان است و با پیشرفت خود جنبه‌های چرخه‌ی حیات فرآیند و فازهای RUP را نشان میدهد. 2. محور عمودی نمایانگر دیسیپلین‌های RUP است كه فعالیتها را با استفاده از ماهیتشان به صورت منطقی دسته‌بندی می‌كند. در هر فاز ممكن است یك یا چند تكرار وجود داشته باشد و در هر تكرار عملیات دیسپیلین‌های مختلف انجام می‌گیرند فازهای RUP فازها و milestone های یك پروژه در RUP Inception (آغازین) هدف اصلی این فاز دستیابی به توافق میان كلیه‌ی ذینفعان بر روی اهداف چرخه‌ی حیات پروژه است. فاز Inception به دلیل تلاشهای تولید و توسعه جدید به صورت پایه‌ای اهمیت فراوانی دارد كه در آن ریسكهای نیازسنجی و تجاری مهمی وجود دارد كه باید پیش از اینكه اجرای پروژه مورد توجه قرار گیرد، بررسی شوند. برای پروژه‌هایی كه بر توسعه سیستم موجود متمركزند، فاز Inception كوتاهتر است، با اینحال این فاز برای حصول اطمینان از اینكه پروژه ارزش انجام دادن دارد و امكان‌پذیر نیز هست، انجام میشود. اهداف اصلی فاز آغازین شامل موارد زیر است: • بدست آوردن محدوده نرمافزاری پروژه و محدودیت‌های آن كه شامل یك دید عملیاتی، معیار پذیرش و اینكه چه چیز باید در محصول باشد و چه چیز نباید باشد، میشود • مشخص كردن Use-Case های اساسی سیستم، سناریوهای اصلی عملیات كه مسائل مربوط به طراحی اصلی را ایجاد می‌كند. • نمایش و شاید توضیح حداقل یك معماری كاندیدا برای بعضی سناریوهای اصلی • برآورد هزینه و زمان كلی برای كل پروژه Elaboration (جزییات) هدف فاز جزئیات تعیین معماری كلی سیستم به منظور فراهم آوردن یك زمینه‌ی مناسب برای قسمت عمده‌ی طراحی و پیادهسازی در فاز Construction است. معماری با درنظرگرفتن بیشتر نیازمندیهای مهم (آن دسته از نیازمندیها كه تأثیر زیادی بر معمار سیستم دارد) و نیز ارزیابی ریسك كامل میشود. پایداری معماری از طریق یك یا چند نمونه‌ی اولیه ساختاری ارزیابی میشود. اهداف اصلی فاز جزئیات شامل موارد زیر است: • اطمینان از اینكه معماری، نیازمندیها و طرحها به اندازه‌ی كافی پایدارند و ریسك‌ها به اندازه‌ی كافی كاهش یافته‌اند بطوریكه بتوان هزینه و زمانبندی لازم برای تكمیل تولید را پیش‌بینی كرد. برای اكثر پروژهها، گذر از این مرحله‌ی مهم مانند انتقال از یك عملیات سبك و سریع و با ریسك پایین به یك عملیات با هزینه و ریسك بالا همراه با اجبار سازمانی است. • بیان همه‌ی ریسكهای پروژه كه از نظر ساختاری اهمیت دارند. • ایجاد یك معماری پایه، مشتق شده از سناریوهای مهم كه از لحاظ ساختاری اهمیت دارند، كه این معماری ریسكهای فنی عمده پروژه را نیز مشخص می‌كند. • تولید یك نمونه‌ی اولیه‌ی تكاملی از مولفه‌های با كیفیت تولیدی خوب، و همچنین یك یا چند نمونه‌ی اولیه‌ی اكتشافی و نمونه‌های اولیه‌ی غیر قابل استفاده جهت كاهش ریسكهای خاص مانند : o سازش‌های مربوط به نیازمندیها یا طراحی o استفاده‌ی مجدد از مؤلفه‌ها o عملی بودن محصول یا توضیحات برای سرمایه گذاران، مشتریان و كاربران نهایی • توضیح اینكه معماری پایه از نیازمندیهای سیستم با هزینه‌ی منطقی و در زمان منطقی پشتیبانی می‌كند • ایجاد یك محیط پشتیبانی كننده Construction (ساخت) هدف این فاز واضح سازی نیازمندیهای باقیمانده و تكمیل تولید سیستم بر اساس معماری مبنا میباشد. فاز ساخت به نوعی یك فرآیند ساخت است كه در آن تأكید بر مدیریت منابع و كنترل عملیات به منظور بهینه‌سازی هزینه‌ها، زمان‌بندی‌ها و كیفیت است. در این حالت یك انتقال از تولید یك نمونه‌ی ذهنی در طی فازهای Inception و Elaboration به تولید محصولات قابل استقرار در طی Construction و Transition میشود. اهداف اصلی فاز Construction شامل موارد زیر میباشد: • كمینه كردن هزینه‌های تولید با بهینه‌سازی منابع و پرهیز از دور انداختن و دوباره‌كاری غیر ضروری • دستیابی هرچه سریعتر به كیفیت كافی • دستیابی هر جه سریعتر به ویرایش‌های مفید (آلفا، بتا و سایر نسخه‌های تست) • كامل كردن تحلیل، طراحی، تولید و تست كارآیی مورد نیاز • تولید تكراری و گام به گام یك محصول كامل كه آماده‌ی انتقال به محیط كاربران باشد • تصمیم در مورد اینكه آیا نرمافزار، سایت‌ها و كاربران همه برای استقرار طرح آمادگی دارند • دستیابی به میزانی از موازی سازی در كار تیم‌های تولید Transition (انتقال) تمركز این فاز بر این است كه تضمین نماید نرمافزار برای كاربران نهایی آماده میباشد. فاز Transition میتواند به چندین تكرار تقسیم شود، و شامل تست كردن محصول برای آماده‌سازی جهت انتشار و ایجاد تنظیمات كوچك بر اساس بازخورد كاربر میباشد. در این نقطه از چرخه‌ی حیات، بازخورد كاربر باید بطور عمده بر تنظیم دقیق محصل، پیكربندی، نصب و نكات مربوط به قابلیت استفاده تمركز یابد، و همه‌ی نكات ساختاری اصلی باید هرچه زودتر در چرخه‌ی حیات پروژه طرح شوند. با به اتمام رسیدن فاز Transition اهداف چرخه‌ی حیات باید برآورده شده باشند و پروژه در موقعیتی باشد كه بتوان آنرا خاتمه داد. در برخی موارد، پایان چرخه‌ی حیات فعلی ممكن است با آغاز چرخه‌ی حیات بعدی در مورد همان محصول همزمان شود و ما را به سمت تولید یا ویرایش دیگری هدایت كند. برای پروژههای دیگر، پایان فاز Transition ممكن است با تحویل كامل خروجیها به گروه سومی كه ممكن است مسؤول عملیات نگهداری و پیشرفت سیستم تحویل دهده شده میباشند، همزمان شود. این فاز بر اساس نوع محصول در فاصله‌ی بسیار ساده تا بی‌نهایت پیچیده قرار دارد. نصب یك نسخه‌ی جدید از یك بسته نرمافزاری موجود ممكن است بسیار ساده باشد، در حالیكه جایگزینی سیستم كنترل ترافیك هوایی یك كشور ممكن است بسیار پیچیده باشد. فعالیتهایی كه در طول یك تكرار در فاز Transition انجام میگیرد به هدف بستگی دارند. برای مثال معمولاً در هنگام رفع اشكالات، پیادهسازی و تست كافی هستند. با این وجود اگر ویژگیهای جدیدی باید اضافه شوند، این تكرار شبیه به تكراری در فاز Construction میشود كه نیازمند تحلیل و طراحی و غیره است. فاز Transition زمانی وارد عمل میشود كه یك خط مبنا آنقدر بالغ شده كه بتواند در دامنه‌ی كاربر نهایی استقرار یابد. این امر بطور نمونه نیازمند این است كه تعدادی زیر مجموعه‌ی قابل استفاده از سیستم با كیفیت قابل قبول و مستندات كاربر، كامل شده باشند، تا انتقال به كاربر نتایج مثبتی را برای همه‌ی گروه‌ها در بر داشته باشد. اهداف مهم فاز Transition عبارتند از: • تست بتا برای تشخیص اعتبار سیستم جدید با توجه به انتظارات كاربر • تست بتا و عملیات موازی همراه با یك سیستم قدیمی كه در حال جایگزینی میباشد. • تبدیل پایگاه‌های داده‌ی عملیاتی • آموزش كاربران و نگهداری كنندگان • بازاریابی، توزیع و فروش برای نخستین انتشار محصول • تنظیم فعالیتها از قبیل رفع اشكال، افزایش كارایی و قابلیت استفاده • ارزیابی خط مبناهای استقرار در مقایسه با تصویر كلی و معیار قابلیت قابل قبول برای محصول • دستیابی به موافقت ذینفع در مورد اینكه خط مبناهای استقرار كامل میباشند • دستیابی به موافقع ذینفع در مور اینكه خط مبناهای استقرار با معیار ارزیابی تصویر كلی سازگارند دیسیپلین‌های RUP دیسیپلین مجموعه‌ای از کارهای به هم مرتبطی است که برای انجام جنبه خاصی از یک پروژه انجام میشوند. متدولوژی RUP دارای 6 دسیسپلین اصلی (مربوط به تولید محصول) و 3 دیسیپلین كمكی (مربوط به تیم و محیط تولید) است كه در ادامه به ترتیب معرفی خواهند شد. Business Modeling (مدلسازی كسب و كار) هداف مدلسازی كسب و كار عبارتند از: • شناخت ساختار و دینامیك‌های سازمانی كه در آن یك سیستم باید استقرار یابد(سازمان هدف.) • شناخت مشكلات فعلی در سازمان هدف و تشخیص پتانسیل‌های بهبود • تضمین اینكه مشتری، كاربر نهایی و تولید كنندگان یك شناخت مشترك از سازمان هدف دارند. • هدایت نیازمندیهای سیستم كه برای حمایت از سازمان هدف مورد نیازند. • دیسیپلین مدلسازی كسب و كار توضیح میدهد كه برای رسیدن به این هدف چگونه میتوان یك تصویر كلی از سازمان را تولید نمود، و براساس این تصویر كلی فرآیندها، نقشها و مسؤولیت‌های آن سازمان را در یك مدل Use-case كسب وكار و یك مدل شیء كسب و كار تعریف كرد Requirements (نیازمندیها) اهداف دیسیپلین نیازمندیها عبارتند از: • تشخیص و نگهداری موارد توافق با مشتری‌ها و سایر ذینفعان در مورد كارهایی كه سیستم باید انجام دهد. • فرآهم آوردن شناخت بهتر از نیازمندیهای سیستم برای تولید كنندگان سیستم • تعریف مرزهای و حدود سیستم • فراهم كردن یك پایه برای طرح ریزی مفاهیم تكنیكی تكرارها • فراهم كردن یك پایه برای تخمین مخارج و زمان تولید سیستم • تعریف یك واسط كاربر برای سیستم با تمركز بر روی نیازها واهداف كاربران برای دستیابی به این اهداف، ابتدا فهم تعریف و محدوده‌ی مسأله‌ای كه سعی داریم با این سیستم آن را حل كنیم، حائز اهمیت میباشد. قوانین كسب و كارف مدل Use-Case كسب و كار و مدل شیء كسب و كار كه در طول مدلسازی كسب و كار تولید شده به عنوان ورودی با ارزشی برای این تلاش خواهند بود. در این راستا ذینفعان تشخیص داده میشوند و درخواستهای ذینفعان استخراج، جمع‌آوری و تجزیه و تحلیل میشوند. یك مستند تصویر كلی، یك مدل Use-Case ، Use-Case ها و مشخصه‌های تكمیلی برای توضیح كامل سیستم تولید میشود. این توضیح درواقع كاری را كه سیستم انجام خواهد داد بیان می‌كند. این مستندات بعنوان منابع مهم اطلاعات تولید میشود. در تولید این مستندات باید خواسته‌های همه ذینفعان را در نظر گرفت. Analysis & Design (تحلیل و طراحی) اهداف تحلیل و طراحی عبارتند از: • تبدیل نیازمندیها به طراحی سیستم كه قرار است بوجود آید. • پیدایش یك معماری مستحكم برای سیستم • سازگار ساختن طراحی برای هماهنگ شدن با محیط پیادهسازی و طراحی آن برای كارایی بهتر در اوایل فاز Elaboration ، بر ایجاد یك معماری ابتدایی برای سیستم تمركز میشود، كه یك معماری كاندیدا برای فراهم كردن یك نقطه‌ی شروع برای تحلیل اصلی ارائه شود. اگر معماری قبلا وجود دارد (یا بدلیل اینكه در تكرارهای قبلی، در پروژههای قبلی تولید شده یا از یك چارچوب كاربردی بدست آمده)، تمركز كار برای اصلاح معماری، تحلیل رفتار و ایجاد یك مجموعه‌ی اولیه از عناصر است كه رفتار مناسب را فراهم می‌آورند Implementation (پیادهسازی) اهداف پیادهسازی عبارتند از: • تعریف سازمان كد، برحسب زیر مجموعه‌ای از مجموعه‌های پیادهسازی سازمان یافته در لایهها • پیادهسازی كلاسها و اشیاء بوسیله مؤلفه‌ها (فایل‌های منبع، باینری‌ها، فایل‌های اجرایی و...) • تست اجزاء تولید شده به عنوان واحد‌ها • مجتمع‌سازی نتایج تولید شده توسط پیاده سازان فردی (یا تیم‌ها) به صورت یك سیستم قابل اجرا دیسیپلین پیادهسازی مرز خود با تست را به اینكه تك تك كلاسها چگونه تست واحد میشوند، محدود می‌كند. تست سیستم و تست مجتمع سازی در دیسیپلین تست انجام میگیرد. Test (آزمون) دیسیپلین تست از بسیاری جهات مانند یك ارائه دهنده خدمات برای سایر دیسیپلین‌ها عمل می‌كند. تمركز اولیه تست كردن بر بررسی و ارزیابی كیفیت‌های محقق شده از طریق كارهای زیر است: • یافتن و مستند كردن نقایص در كیفیت نرمافزار • آگاهی دادن در مورد كیفیت نرمافزار بررسی شده • اثبات اعتبار فرضیاتی كه در طراحی و مشخصات نیازمندیها ساخته شدند، از طریق نمایش‌های واقعی • تصدیق عملكردهای محصول نرمافزار همانطور كه طراحی شده است. • تصدیق اینكه نیازمندیها بدرستی پیادهسازی شده‌اند یك تفاوت جالب ولی تاحدی ظریف میان دیسیپلین تست و سایر دیسیپلین‌ها در RUP این است كه تست گرفتن، اساسا وظیفه‌ی یافتن و ارائه ضعف‌ها در محصول نرمافزار را داراست. برای اینكه این تلاش موفقیت‌آمیز باشد، لازم است از یك روش نسبتا منفی و مخرب استفاده شود تا روشی سازنده. مسأله‌ای كه بسیار حائز اهمیت میباشد این است كه از دو روش اجتناب كنیم : یكی روشی كه بطور مناسب و موثر نرمافزار را بكار نگیرد و مشكلات و ضعف‌های آن را نشان ندهد و دیگری روشی كه آنقدر مخرب است كه احتمالا هیچگاه كیفیت محصول نرمافزاری را قابل قبول درنظر نمی‌گیرد. Deployment (استقرار) دیسیپلین استقرار فعالیتهایی را توضیح میدهد كه تضمین می‌كنند محصول نرمافزاری برای كاربران نهایی‌اش در دسترس میباشد. دیسیپلین استقرار سه حالت استقار محصول را توضیح میدهد. • نصب اختصاصی • آماده فروش كردن محصول نهایی • دستیابی به نرمافزار از طریق اینترنت در هر نمونه، تأكید روی تست محصول در سایت تولید است و سپس انجام تست بتا، پیش از اینكه محصول نهایتا به مشتری تحویل داده شود. گرچه فعالیتهای استقرار در فاز Transition به منتها درجه‌ی خود می‌رسند، اما برخی از فعالیتها در فازهای قبلی برای طرح‌ریزی و آمادگی جهت استقرار انجام میشوند. Environment (محیط) دیسیپلین محیط بر فعالیتهایی كه برای پیكربندی فرآیند برای یك پروژه لازم و ضروری‌اند، متمركز میشود. این دیسیپلین فعالیتهای مورد نیاز برای تولید رهنمودهایی كه در جهت پشتیبانی از یك پروژه لازم میباشند را توضیح میدهد. هدف فعالیتهایی محیطی فراهم آوردن محیط تولید (هم فرآیندها و هم ابزاری كه تیم تولید را پشتیبانی می‌كنند) برای سازمان تولید كننده نرمافزار میباشد. جعبه ابزار مهندس فرآیند پشتیبانی ابزاری را برای پیكربندی یك فرآیند فراهم می‌كند. این مورد شامل ابزارها و نمونه‌هایی برای ایجاد سایتهای وب پروژه و سازمان بر اساس RUP میشود. Project Management (مدیریت پروژه) مدیریت پروژه نرمافزاری، هنر متوازن ساختن اهداف متقابل، مدیریت ریسك و غلبه بر محدودیت‌ها برای تحویل موفقیت آمیز محصولی است كه هم نیازهای مشتریان ( كسانی كه برای سیستم پول می‌پردازند) و هم نیازهای كاربران را برآورده كند. این حقیقت كه پروژههای بسیار كمی هستند كه واقعا موفقیت‌آمیزند برای توضیح سخت بودن این كار، كافی میباشد اهداف این دیسیپلین عبارتند از: • فراهم كردن یك چارچوب برای مدیریت پروژههای صرفاً نرمافزاری • فراهم كردن رهنمودهای عملی برای طرح‌ریزی، تعیین نیروی انسانی، اجرا و نظارت بر پروژهها • فراهم كردن یك چارچوب برای مدیریت ریسك • با این وجود، این دیسیپلین از RUP برای پوشش دادن همه‌ی جنبه‌های مدیریت پروژه نیست. برای مثال این دیسیپلین موارد زیر را پوشش نمیدهد : * مدیریت افراد : استخدام، آموزش، رهبری * مدیریت بودجه : تعیین، تخصیص و غیره * مدیریت قراردادها : با پشتیبانی كنندگان و مشتریان این دیسیپلین بطور عمده روی جنبه‌های مهم یك فرآیند تكراری تمركز می‌كند كه عبارتند از : * مدیریت ریسك * طرح ریزی برای یك پروژه‌ی تكراری، از طریق چرخه‌ی حیات و برای یك تكرار بخصوص * نظارت بر پیشرفت یك پروژه‌ی تكراری و متریك‌ها Configuration & Change Management (مدیریت پیكربندی و تغییرات) برای تأویل و تفسیر ”مدل بلوغ قابلیت“ انستیتو مهندسی نرمافزار( SEI CMM )، مدیریت پیكربندی و درخواست تغییر، تغییرات را به سمت خروجیهای یك پروژه كنترل می‌كند و همچنین صحت و تمامیت خروجیهای پروژه را حفظ می‌كند. مدیریت پیكربندی و درخواست تغییر ( CRM, CM ) شامل موارد زیر میباشند: • تشخیص موارد پیكربندی • محدود كردن تغییرات آن موارد • رسیدگی به تغییراتی كه برای آن موارد ساخته شده • تعریف و مدیریت پیكربندی آن موارد متدها، فرآیندها و ابزاری كه برای ایجاد تغییر و مدیریت پیكربندی برای یك سازمان استفاده میشوند، میتوانند بعنوان سیستم CM سازمان مورد توجه قرار گیرند. سیستم مدیریت پیكربندی و درخواست تغییر (سیستم CM ) برای یك سازمان اطلاعات كلیدی در مورد تولید محصول را نگهداری می‌كند. این اطلاعات عبارتند از : ترفیع، استقرار و فرآیندهای نگهداری. بعلاوه یك پایگاه داده محصولاتی را كه بصورت بالقوه قابل استفاده مجدد میباشند، نگهداری می‌كند. یك سیستم CM برای كنترل خروجیهای متعدد تولید شده توسط افراد زیادی كه روی یك پروژه كار می‌كنند، ضروری است. كنترل، به اجتناب از اغتشاشِ پرهزینه كمك می‌كند و تضمین مینماید كه خروجیهای بدست آمده با توجه به برخی انواع مسائل و مشكلاتی كه در زیر آمده‌اند ناسازگار نیستند. • به روز رسانی همزمان • توجه دادن محدود شده • نسخه‌های چندگانه 
|
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
|
هردو نوع مدلسازي لازم است |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| مدل کسب و کار یک snapshot از کسب و کار می باشد که چگونگی پیکربندی یک کسب و کار را نشان می دهد . مدل کسب و کار این است که چگونه کسب و کار شما با ایجاد یک سرویس موثر تبدیل به منابع پرسود می شود که شامل استراتژی کسب و کار (ارزش برای ایجاد یک کسب و کار )، ساختار (چگونه مردم، فرآیندها و شرکا اقدام به ایجاد و ارائه ارزش می نمایند ) و زیرساخت و فناوری است که ایجاد ارزش و تحویل آن را قادر می سازد. مدل کسب و کار مفهوم "چگونگی" در کسب و کار است. این یک توصیف سطح بالا از عواملی مانند چگونگی اضافه کردن ارزش، مشتریان هدف، شرکا، هزینه ها، و غیره می باشد . مدل سازی سیستم نشان دهنده یک سیستم خاص بوده، بنابراین شرح موارد مورد نیاز، ساختار، برنامه ریزی، طراحی، و غیره می تواند یک دید سطح بالا باشد، اما به چیزی خاص تر در مورد کسب و کار اشاره دارد. مدل سازی فرآیند کسب و کار (BPM) در سیستم های مهندسی فعالیت نمایش فرآیندهای سازمانی را برعهده دارد . |
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| سلام علیکم، مهمترین مزایای مدل کردن فرآيند های سازمانی حفظ پیوستگی در تصمیم گیری های سازمان است. با وجود مدل مستند کسب و کار، پس از تغییرات احتمالی در تیم مدیریت، سازمان دچار سردرگمی و احیاناً تغییرات عمده نمی شود. بلکه تیم مدیریت جدید جهت بهبود مدل قبلی تلاش خواهند کرد و اینگونه است که پیوستگی موفقیت و ثبات یک سازمان حتی پس از مرگ شخص اول آن ادامه دار می ماند. مزیت دیگر، عدم سردرگمی نیروهای انسانی جدید است. در صورت تغییر در پست های سازمانی و یا جذب نیروی جدید، به کمک این مدل، آنها از سردرگمی نجات خواهند یافت و دیگر نیازی نیست تا پس از گذشت یک ماه نیروی جدید درک خوبی از وظایفش و فرآيند عملکردش پیدا کند. برخی از مهمترین مزایای استاندارد سازی علائم مورد استفاده در مدل سازی فرآيند به شرح زیر است: • ایجاد تفکر مشترک و گروهی • تسهیل ارتباطات • ایجاد درک متقابل • راهکار دسترسی به کیفیت • راهکار بهبود مستمر • عامل اعتماد مشتری • عامل رضایت مشتری • راهکار تشخیص و پیشگیری • راهکار کنترل • کاهش هزینه و ضایعات افراد درگیر در تیم مدلسازی فرآيند: ۱- کارشناس کسب و کار: کسی که دانش زیادی درباره فرآيند دارد. ۲- صاحب فرآيند: فردی که مسئول اجرای کل فرآيند است و اصلاحات فرآيند را تایید می کند. ۳- مدیر یا میانجی: مسئول قرار ملاقات ها، برای پرسیدن سوال جهت راهنمایی برای گرفتن تصمیم درست است. 4- کارشناس مدل سازی: مسئول طراحی مدل فرآيند است. اصول تفكر سيستمي رشد سريع علوم، تکنولوژي، اقتصاد، مديريت اجتماعي و بطور کلي رشد سريع جوامع بشري، باعث شده نوع مشکلات و مسائل در جوامع بشري به سرعت تغيير يابد و بنابراين براي غلبه بر مسائل بايد يادگيري مديران و سياستگذاران از سيستمها بيشتر شود. بسياري از مسائل و مشکلات دنياي امروز، در حقيقت به علت اجراي تصميمات گذشته مديران و سياستگذاران بوده است و اين به معني آن است که مديران قبلي نسبت به نحوه تعاملات اجزاي درون سيستمها، اطلاع دقيقي نداشته اند. در حقيقت، مشکلات و مسائلي که در زمنيه‌هاي اجتماعي ايجاد ميشود و سياستگذاران خواهان حل آنها هستند، همانند رفتارهاي نامطلوب متغيرهايي از پديده‌هاي اجتماعي (سيستمهاي اجتماعي) است که تحليل گران سيستمها مي‌خواهند با کمک تفکر سيستمي و ابزارهاي آن، رفتار مطلوب را به سيستم برگردانند. |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
System Modeling یک مطالعه میان رشته ای از استفاده مدل ها جهت درک و ساخت سیستم ها در کسب و کار و IT می باشد. نوع رایجی از مدلسازی سیستمی Function Modeling است، که از تکنیک های خاصی از قبیل Functional Flow Block Diagram و IDEF0 استفاده می کند. نوع دیگری از مدلسازی سیستمی architectural modeling می باشد که از معماری سیستم ها برای مدلسازی ساختار، رفتار و view های دیگر سیستم استفاده می کند. Business Process Modeling Notation (BPMN)، که یک نمایش گرافیکی برای مشخص کردن فرآیندهای تجاری در یک جریان کاری می باشد، نیز می تواند بعنوان یک زبان مدلسازی سیستمی در نظر گرفته شود. |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| با سلام و احترام به دوستان چرا هر دو نوع مدلسازي(كسب و كار و سيستمي) مورد نياز است؟ همانطور که دوستان نیز در پست های خود به آنها اشاره نمودند نیاز به هر دو مدلسازی (كسب و كار و سيستمي) ضروری می باشد بنابراین این دو مدلسازی در کنار یکدیگر تکمیل کنند بوده چرا که در "مدل کسب و کاری" نحوه کسب و کار و درآمد سازمان با توجه به جایگاه آن سازمان مشخص و تشریح می شود که این امر ابزاری می شود هم برای تامین منافع مشتری وهم مناقع سازمان یا به عبارتی کسب و کار همچنین لازم بذکر می باشد که "مدل سیستمی" نیازمندی های سازمان شناسایی شده و گردش کار سیستم در قالب مدل و نشانه های استاندارد مستند شده و در اختیار سازمان قرار میگیرد نا در صورت لزوم توسعه دهندگان سیستم بتوانند طراحی های مورد نیاز خود را در مدل ایجاد و یا تغییر دهند. با بیان توضیحات بالا وجود این دو نوع مدل در کنار یکدیگر ضروری می باشد. ابزارهاي مورد استفاده براي هر رويكرد چه ابزارهايي مي باشد؟ در مدل کسب و کار می توان اینگونه بیان نمود: Use case diagrams(integrated in UML) Activity diagrams (also adopted by UML) در مدل سیستمی می توان اینگونه بیان نمود: Artisan Studio Sparx Systems Enterprise Architect ChangeVision Astah SysML IBM Rational Rhapsody Papyrus Visual Paradigm رويكرد متدولوژي هاي مختلف(نظير SSADM به عنوان نماينده رويكرد ساخت يافته و RUP به عنوان نماينده رويكرد شي گرا) در اين زمينه چيست؟ تا چه اندازه بايد به مدلسازي كسب و كار اهميت داد ؟ http://www.smhoseyni.com/img/rup_phases.png رویکرد SSADM : • امکان سنجي • تحليل نيازها • تعيين مشخصات نيازمنديها • مشخصات سيستم منطقي • طراحي فيزيکي رویکرد RUP: Ø آغازين Ø طراحي جزئيات Ø ساخت Ø انتقال تا چه اندازه بايد به مدلسازي كسب و كار اهميت داد و تا چه اندازه بايد به مدلسازي سيستمي پرداخت؟ به نظر من اهمیت دادن به این دو بسته به انتظار ما از آن مدل می باشد ولی بصورت کلی میتوان بیان نمود که اهمیت دادن به هر دو مدل لازم بوده و اندازه آن می بایست تا حدی بوده که ما را به انتظارات و اهداف در سازمان نزدیک نماید. با تشکر قلیزاده |
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| با سلام و احترام به دوستان چرا هر دو نوع مدلسازي(كسب و كار و سيستمي) مورد نياز است؟ همانطور که دوستان نیز در پست های خود به آنها اشاره نمودند نیاز به هر دو مدلسازی (كسب و كار و سيستمي) ضروری می باشد بنابراین این دو مدلسازی در کنار یکدیگر تکمیل کنند بوده چرا که در "مدل کسب و کاری" نحوه کسب و کار و درآمد سازمان با توجه به جایگاه آن سازمان مشخص و تشریح می شود که این امر ابزاری می شود هم برای تامین منافع مشتری وهم مناقع سازمان یا به عبارتی کسب و کار همچنین لازم بذکر می باشد که "مدل سیستمی" نیازمندی های سازمان شناسایی شده و گردش کار سیستم در قالب مدل و نشانه های استاندارد مستند شده و در اختیار سازمان قرار میگیرد نا در صورت لزوم توسعه دهندگان سیستم بتوانند طراحی های مورد نیاز خود را در مدل ایجاد و یا تغییر دهند. با بیان توضیحات بالا وجود این دو نوع مدل در کنار یکدیگر ضروری می باشد. ابزارهاي مورد استفاده براي هر رويكرد چه ابزارهايي مي باشد؟ در مدل کسب و کار می توان اینگونه بیان نمود: Use case diagrams(integrated in UML) Activity diagrams (also adopted by UML) در مدل سیستمی می توان اینگونه بیان نمود: Artisan Studio Sparx Systems Enterprise Architect ChangeVision Astah SysML IBM Rational Rhapsody Papyrus Visual Paradigm رويكرد متدولوژي هاي مختلف(نظير SSADM به عنوان نماينده رويكرد ساخت يافته و RUP به عنوان نماينده رويكرد شي گرا) در اين زمينه چيست؟ تا چه اندازه بايد به مدلسازي كسب و كار اهميت داد ؟ فاز های SSADM : • امکان سنجي • تحليل نيازها • تعيين مشخصات نيازمنديها • مشخصات سيستم منطقي • طراحي فيزيکي فاز های RUP: Ø آغازين Ø طراحي جزئيات Ø ساخت Ø انتقال تا چه اندازه بايد به مدلسازي كسب و كار اهميت داد و تا چه اندازه بايد به مدلسازي سيستمي پرداخت؟ به نظر من اهمیت دادن به این دو بسته به انتظار ما از آن مدل می باشد ولی بصورت کلی میتوان بیان نمود که اهمیت دادن به هر دو مدل لازم بوده و اندازه آن می بایست تا حدی بوده که ما را به انتظارات و اهداف در سازمان نزدیک نماید. با تشکر قلیزاده |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
به نظرم مي رسد مي توانيم تفاوت اين دو مدلسازي را به صورت جدول زير خلاصه كرد 
|
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
پس از مطالعه اسناد و مطالب مختلف جواب اين سئوالات را به صورت جدول زير خلاصه و جمع بندي كردم :
|
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
https://sourcemaking.com/uml/modeling-business-systems/business-processes-and-business-systems
|
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| خانم رضايي كاش چند خط توضيح هم مي نوشتيد |
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| مدل business به "چگونگي" کسب و کار مي پردازد. این یک توصیف سطح بالا از عوامل مانند چگونگي افزايش: ارزش، مشتریان هدف، شرکا، هزینه ها، و غیره. است. مدل سازی سیستم نشان دهنده یک سیستم خاص بوده و به شرح نیازها، ساختار، برنامه ریزی، طراحی، و غیره مي پردازد. همچنین یک دید سطح بالا است، اما آن به چیزهاي خاص بیشتري در مورد کسب و کار اشاره دارد. منبع http://www.quora.com/What-is-the-difference-between-business-modeling-and-system-modeling |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| با توجه به اینکه اکثر دوستان مطالب رو از سایت های مختلف استخراج می کنند اما به طور کلی سطح مشارکت کلاسی بسیار مناسب هست هر چند که نیاز به به کارگیری نظرات شخص دانشجو و رفرنس به مراجع و منابع معتبر تر هست |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| Business model is "the how" of the business. It's a high level description of factors like how to add value, target customers, partners, costs, etc System modeling represents a specific system, so description of requirements, structure, planning, design, etc. This can be also a high level view, but it refers to something more specific about the business |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
|
چرا مدل و مدلسازی ؟
ایجاد یک مدل برای سیستمهای نرم افزاری قبل از ساخت یا بازساخت آن، به اندازه داشتن نقشه برای ساختن یک ساختمان ضروری و حیاتی است. بسیاری از شاخه های مهندسی، توصیف چگونگی محصولاتی که باید ساخته شوند را ترسیم می کنند و همچنین دقت زیادی می کنند که محصولاتشان طبق این مدلها و توصیفها ساخته شوند. مدلهای خوب و دقیق در برقراری یک ارتباط کامل بین افراد پروژه، نقش زیادی می توانند داشته باشند. شاید علت مدل کردن سیستمهای پیچیده این باشد که تمامی آن را نمی توان یک باره مجسم کرد، بنابراین برای فهم کامل سیستم و یافتن و نمایش ارتباط بین قسمتهای مختلف آن، به مدلسازی می‌پردازیم. چرا BPMN مهم است؟ چرا BPMN در اجرای صحیح یک BPM مهم است؟ ذكر يك مثال : فرآیند زیررا بعنوان یک فرآیند استخدام در نظر بگیرید.  این فرآیند از تعریف شغل آغاز میگردد. سپس لازم است برای شغل تعریف شده نیروی انسانی جذب شود. با اولین بررسی این فرآیند، سوالاتی به ذهن خطور مینماید، اما آیا نمودار فوق قادر است به سوالات زیر پاسخ دهد؟!
مسلما در نمودار فوق به سوالات مطرح شده پاسخ داده نخواهد شد. BPMN توانایی دارد علاوه بر ترسیم یک فرآیند به تمام سوالات فوق در آن فرآیند پاسخ دهد. BPMN برای این مهم است که یک زبان استاندارد است و مخصوص طراحی فرآیند و پاسخ گوی سوالات پیش رو است. BPMN می تواند به خوبی با بکارگیری نماد های گرافیکی ساده علاوه بر ترسیم نمودار فوق به تمام سوالات مرتبط با فرآیند پاسخ دهد. BPMN محدوده جغرافیایی نداشته و تمام افراد در سراسر دنیا میتوانند فرآیند های ترسیم شده با آن را مطالعه و پاسخ های مناسبی برای سوالات خود دریافت کنند. BPMN زبانی مشترک برای گروه های کاری دورن سازمانی و برون سازمانی است. BPMN باعث میگردد تمام فرآیند ها و تحلیلگران فرآیند های سازمان با یک زبان با یکدیگر گفتگو نمایند. BPMN توانایی بالایی در بازگو کردن قوانین و حالت های رخداد های سازمان دارد. BPMN یک درک صحیح از فرآیند را بین افراد سازمان به اشتراک میگذارد به گونه ای که افراد سازمان معنای عمیق و صحیحی از فرآیند در دریافت مینمایند. BPMN استاندار سازی فرآیند های دورن سازمانی و برون سازمانی را تسهیل مینماید. چرا uml ؟ UML یا زبان مدلسازی یکنواخت، زبانی است برای مشخص کردن (Specify)، مصورسازی (Visualize)، ساخت (Construction) و مستندسازی (Documenting) سیستمهای نرم افزاری و غیر نرم افزاری و نیز برای مدلسازی سیستمهای تجاری. ویژگیهای UML
|
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
|
1. چرا هر دو نوع مدلسازي(كسب و كار و سيستمي) مورد نياز است؟
Business Model: مدل کسب و کار چارچوبی برای خلق پول و ثروت است. به بیان ساده عبارت از متدی است که شرکت در فعالیتهای تجاری در پیش گرفته و با کسب درآمد ثبات خود را حفظ می نماید. به تعبیری دیگر;مدل کسب و کار چگونگی کسب درآمد توسط بنگاه را با مشخص کردن جایگاه آن در زنجیره ارزش مشتری تشریح می کند.(مدل کسب و کار ابزاری برای تامین منافع مشتری و منافع بنگاه و کسب در آمد)
System Modeling:. بسياري از شاخه هاي مهندسي، توصيف چگونگي محصولاتي كه بايد ساخته شوند را ترسيم مي كنند و همچنين دقت زيادي مي كنند كه محصولاتشان طبق اين مدلها و توصيفها ساخته شوند. مدلهاي خوب و دقيق در برقراري يك ارتباط كامل بين افراد پروژه، نقش زيادي مي توانند داشته باشند. شايد علت مدل كردن سيستمهاي پيچيده اين باشد كه تمامي آن را نمي توان يك باره مجسم كرد، بنابراين براي فهم كامل سيستم و يافتن و نمايش ارتباط بين قسمتهاي مختلف آن، به مدلسازي مي‌پردازيم
2. ابزارهاي مورد استفاده براي هر رويكرد چه ابزارهايي مي باشد؟
Business Modeling : ابزار BPMN r Online Business Model Course Business Model Canvas Poster
System Modeling : زبان UML –استفاده از نرم افزار STELLA IBM Rational Rhapsody Lattix Architect Modelio Innoslate Papyrus Software Ideas Modeler SysML Designer Visual Paradigm
3. رويكرد متدولوژي هاي مختلف(نظير SSADM به عنوان نماينده رويكرد ساخت يافته و RUP به عنوان نماينده رويكرد شي گرا) در اين زمينه چيست؟ متدلوژي SSADM يك رویکرد سیستمي است براي تجزیه و تحلیل و طراحی سیستم های اطلاعاتی است
SSADM روشهایی برای ثبت و مستندسازی فعالیت ها ارائه داده است و مشخص می نماید که در هر مرحله از توسعه و ایجاد سیستم چه مستنداتی تولید شود
این متدولوژی دارای محدودیتهایی می باشد و به همین دلیل برای تحلیل سیستمهای بزرگ از این نوع متدولوژی استفاده نمی شود.
4. تا چه اندازه بايد به مدلسازي كسب و كار اهميت داد و تا چه اندازه بايد به مدلسازي سيستمي پرداخت؟
Business Modeling : در این مدل با توجه به منابع در دسترس و نیاز مشتری، پیشنهادی برای عرضه ارزش مورد نظر مشتری ارائه شده و منافع و درآمد نصیب شرکت می سازد. System Modeling : ايجاد يك مدل براي سيستمهاي نرم افزاري قبل از ساخت يا بازساخت آن، به اندازه داشتن نقشه براي ساختن يك ساختمان ضروري و حياتي است |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| فرآيندهای کسب و کار از فعالیت های هماهنگ اجرا شده كه برخی از اهدف کسب و کار را مورد توجه قرار مي دهند تشکیل شده است. فعالیت؛ عمل یا کاری است که از طریق فرآيندهای کسب و کار انجام می شود. این فعالیت ها که به صورت هماهنگ اجرا می شوند، می توانند فعالیت های سیستم، فعالیت های کاربر تعامل، یا فعالیت های دستي باشند. فعالیت های دستی توسط سیستم های اطلاعاتی پشتیبانی نمی شود. نمونه ای از یک فعالیت دستي، ارسال بسته به یک شریک تجاری است. فعالیت های کاربر تعامل که کاركنان دانشي آنها را انجام می دهند از سیستم های اطلاعاتی استفاده مي کنند. در آنجا هیچ فعالیت فیزیکی وجود ندارد. نمونه ای از یک فعالیت تعامل انسانی وارد کردن اطلاعات در مورد ادعای بیمه در یک محیط مرکز تماس است. از آنجا که انسان از سیستم های اطلاعاتی برای انجام این فعالیت ها، استفاده مي كند، بنابراين برنامه های کاربردی بايد رابط کاربر مناسب داشته باشند تا بتوانند مؤثر باشند. این برنامه نیاز به اتصال به back-end سیستم های اطلاعاتي موجود که اطلاعات وارد شده در آن ذخيره شده اند دارد تا آن را برای استفاده های بعدی در دسترس قرار دهد. بعضي از فعالیت ها که در طول فعال سازی فرآيند کسب و کار منتقل مي شود، از ماهیت فعالیت های دستي هستند، اما تغییرات حالت در سیستم مدیریت فرآيند کسب و کار با استفاده از فعالیت هاي کاربر تعامل، وارد شده است. به عنوان مثال، تحویل بسته را می توان با یک سیستم اطلاعات به تصوير كشيد. به طور معمول، تحویل واقعی بسته توسط گیرنده با امضای او كه شناخته شده است، انجام مي شود.تحویل واقعی اطلاعات مهم در فرآيندهای لجستیک (تداركاتي) کسب و کار است که باید به درستی توسط سیستم های اطلاعاتی ارائه شود. زبان نشانه گذاريِ مدل سازي فرآيند های كسب و کار (Business Process Modeling Notation(BPMN استانداردی جهت تدوین دیاگرام فرآيندهای کسب و کار است. شامل مجموعه ای از اشکال گرافیکی (هندسی) می باشد که مبتنی بر نمودار گردشی Flowchart توسعه یافته اند. هدف اصلی نشانه گذاريِ مدل سازي فرآيند های كسب و کار فراهم نمودن مدلی است قابل فهم برای تمام افرادی که در کسب و کار سازمان دخیل هستند، مانند سهامداران، مدیران عالی، مشتریان و …. برای مثال در صورتی که ما درک خوبی از روند انجام پیگیری سفارش در سازمان داشته باشيم می توانيم آن را بصورت بهینه و شایسته تر در سیستم مدیریت روابط مشتریان پیاده سازی کنيم. در واقع در این شرایط ما میتوانيم در جهت بهبود کیفیت و افزایش بهره وری، محصول مؤثرتری تولید کنيم که در آن کوتاه کردن مسیر فرآيند، کنترل هزینه، استفاده بهتر از نیروی انسانی و همچنین اطلاع رسانی بهتر به مشتری لحاظ شده باشد. متدولوژی Rup یک فرآیند تولید و توسعه نرم افزاری می باشد .مهم ترین هدف Rup اطمینان از تولید نرم افزار با کیفیت بالا می باشد. تولید نرم افزار با استفاده از متدلوژی Rup براساس یک روش تکرار شونده می باشد بدین صورت که در تولید یک محصول تعدادی تکرار در نظر گرفته می شود این تکرارها در فاز های Rup صورت می پذیرد در هر فاز Rup ممکن است چندین تکرار داشته باشیم و در پایان هر تکرار یک محصول قابل ارائه وجود دارد. این محصول در پایان هر تکرار کامل تر شده و در نهایت در آخرین تکرار محصول نهایی ارائه می گردد. 
|
|
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| بررسي تأثير متدولوژي SSADM، كه يكي از بهترين و رايجترين متدولوژيهاي شناخته شده در طراحي و پياده سازي سيستمهاي اطلاعاتي ميباشد، بر افزايش كيفيت تصميم گيري و انعطاف پذيري و همچنين كاهش ميزان خطا در تصميم گيري مي‌پردازد. متدولوژي SSADM يک متدولوژي داده مدار است و توجه خاصي به طراحي پايگاه هاي اطلاعاتي دارد. کي از مزاياي مهم SSADM استفاده از طيف وسيعي از ابزارها و تکنيکها براي پيشبرد مراحل توسعه سيستم مي باشد. SSADM ابزارهاي استاندارد مختلفي براي اجراي هر گام و هر عمل ارائه مي نمايند. ابزارهاي مورد استفاده در متدولوژي SSADM را مي توان به دو دسته ابزارهاي نموداري و غيرنموداري تقسيم نمود. در اين قسمت، به طور خلاصه به معرفي پاره اي از مهمترين ابزارها و روشهاي اين متدولوژي مي پردازيم : ابزارهاي نموداري · نمودارهاي جريان داده (DFD) DFD يکي از پرکاربردترين ابزارها در SSADM به شمار مي رود. اين مدل در عين سادگي، ابزار ارتباطي بسيار پر قدرتي به شمار مي رود که به راحتي براي کاربر قابل فهم مي باشد. هر DFD ارائه کننده يک سيستم اطلاعاتي از ديدگاه جهت حرکت داده مي باشد که شامل داده هاي ورودي و خروجي به سيستم مورد مطالعه مي باشد. مزيت ديگرDFD قابليت ترسيم آن در سطوح اطلاعاتي مختلف مي باشد. بنابراين يک نمودار مي تواند ديدگاهي کلي از محدوده مورد مطالعه را به دست دهد. DFD ها معمولا توسط اطلاعات جزيي که در فرهنگ داده ها نگهداري ميشود، پشتيباني مي گردد. اين نمودارها جهت تعيين خطوط کلي فعاليتهاي موجود مورد استفاده قرار مي گيرند و ابزار مفيدي براي انجام مصاحبه ها به شمار مي روند. تکنيک DFD در حقيقت براي نخستين بار در روش دومارکو معرفي گرديد که با کمي تغيير در علامت گذاريها، در روش SSADM هم به کار گرفته ميشود. DFD ها به طور وسيعي در مراحل اوليه SSADM براي تعريف سيستم اطلاعاتي به کار گرفته مي شوند. اين نمودارها، همچنين ابزار مهمي براي ارتباط با کاربر در خلال تعريف و انتخاب گزينه سيستم کاري (مرحله 2) به شمار مي رود. در خلال مرحله 3، DFD ها براي نمايش نيازمنديهاي سيستم انتخاب شده در مرحله 2 به کار گرفته ميشود. در هر حال، استفاده از DFD ها بعد از گام استخراج کارکردهاي سيستم (گام 3.3) به پايان مي رسد. · ساختارهاي منطقي داده (LDS ) o معرفي و تعريف داده هايي که سازمان براي انجام عمليات خويش نيازمند به نگهداري آنها است o توصيف اين داده ها به روشي ساده و منطقي مستقل از هرگونه عمليات فيزيکي ويژه o تسهيل و روشن سازي رابطه بين توسعه دهنده و کاربر همانطور که گفته شد متدولوژي SSADM يک متدولوژي داده مدار است و توجه خاصي به طراحي پايگاه هاي اطلاعاتي دارد. اين خصلت مي تواند براي به کارگيري اين روش در طراحي سيستم هاي اطلاعاتي گسترده يک امتياز کلي تلقي گردد. از سوي ديگر اين متدولوژي در سطح کشور، متدولوژي شناخته شده اي به شمار مي رود و بسياري از نهادها و مراکز مرتبط با مقوله طراحي سيستم حداقل به طور کلي با آن آشنايي دارند. قابل دسترس بودن پاره اي از مستندات و مکتوبات تشريح کننده اين متدولوژي در سطح کشور از ديگر مزاياي عمده اين روش است . اکثر ابزارهاي CASE متداول در ايران، اين متدولوژي را پشتيباني مي کنند. يکي از بزرگترين نقاط ضعف SSADM، اهميت نسبتاً ناچيزي است که در آن به مرحله برنامه ريزي راهبردي داده ميشود. به همين دليل اکثر سازمانهايي که به دنبال راه حلهاي جامعي براي سيستم هاي اطلاعاتي خود مي گردند، به سراغ متدولوژيهاي ديگري که به برنامه ريزي راهبردي بهاي بيشتري مي دهند، رفته اند. |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| همیشه در پروژه ها نیاز به انجام مدلسازی کسب و کار نیست. اين نظم معمولا درسیستم ها يي که دارای خصايص زير است انجام می شود: - سیستم ها يي که دارای فرايند ها ی کسب و کارپیچیده می باشند (جهت فهم بهتر فرايند ها ی کاری سیستم) - سیستم ها يي که نیاز به انجام اصلاحات در جهت بهبود فرايند ها ی کسب و کارخود دارند. - سیستم ها يي که دارای تعداد کاربران زياد است. - زمانی که حجم داده ها يي که سیستم می بايست پردازش نمايد زياد است. ابزارهای شرکت Rational جهت نظم مدلسازی کسب و کار عبارتند از: Rose- جهت مدلسازی تصويری با استفاده از نمادهای UML : Requisite Pro - جهت نگاهداری بخشهای متنی مدل های تولیدشده توسط Rose : SoDA - برای خودکارسازی فرايند تولید مستندات مدل سازی سیستم : يک فرآيند توسعه مجرد ازمدلهای يک سیستم است. با هر مدل يک ديد و دورنمای خاص از آن سیستم ارايه می شود. مدل سازی سیستم منظور سیستم را به نوعی با استفاده از بعضی انواع علايم گرافیکی بیان می کند. اين مدل سازيها غالبا با کمک زبان مدل کردن يکسان (UML) انجام میگردد. مدل سازی سیستم به تجزيه و تحلیلگران سیستم برای فهمیدن وظايف آن کمک می کند و بیشتر برای ارتباط با مشتری استفاده می شود. منبع : http://set-quast.persiangig.com/document/mabanimohandesi/Soft_engin_4.ppt/download |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| با سلام و عرض ادب با توجه به مطالب دوستان نتيجه گيري هاي زير رو ميتوان داشت . در مورد سوال اول مدل کسب و کار چارچوبی برای خلق پول و ثروت است اما در مدل سازی سیستم به تجزيه و تحلیلگران سیستم برای فهمیدن وظايف آن کمک می کند و بیشتر برای ارتباط با مشتری استفاده می شود در رابطه با سوالات دوم و سوم دوستان به طور كامل اشاره نمودند و اما در رابطه با سوال سوم هر دو كامل كننده همديگر و بسته به سازمان درصد استفاده از هر يك متفاوت مي باشد اما در لزم به استفاده از مدل كسب و كار در همه سيستم ها نمي باشد. با تشكر هادي زمردي 
|
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
| عرض سلام و ادب و احترام خدمت تک تک دوستان اگر اجازه بدید بنده تمام این مبحث رو ملاحظه کنم و امتیاز فعالیت ها رو ثبت کنم بنا بر این خواهش می کنم از ساعت 24 روز 17 خرداد (بعد از امتحان) هیچ پستی رو اضافه نکنید بسیار بسیار متشکرم |
 |
پاسخ: مبحث مشارکتی: تفاوت مدلسازی Business و System
|
|
ابزار مدلسازی فر آیند :
ابزار مدلسازی کسب و کار : Topcased چرا هر دو نوع مدلسازي(كسب و كار و سيستمي) مورد نياز است؟ مدلسازی کسب و کار : به بیان ساده عبارت از متدی است که شرکت در فعالیتهای تجاری در پیش گرفته و با کسب درآمد ثبات خود را حفظ می نماید. در این مدل با توجه به منابع در دسترس و نیاز مشتری، پیشنهادی برای عرضه ارزش مورد نظر مشتری ارائه شده و منافع و درآمد نصیب شرکت می سازد. به تعبیری دیگر;مدل کسب و کار چگونگی کسب درآمد توسط بنگاه را با مشخص کردن جایگاه آن در زنجیره ارزش مشتری تشریح می کند.(مدل کسب و کار ابزاری برای تامین منافع مشتری و منافع بنگاه و کسب در آمد) مدلسازی سیستمی: ايجاد يك مدل براي سيستمهاي نرم افزاري قبل از ساخت يا بازساخت آن، به اندازه داشتن نقشه براي ساختن يك ساختمان ضروري و حياتي است. بسياري از شاخه هاي مهندسي، توصيف چگونگي محصولاتي كه بايد ساخته شوند را ترسيم مي كنند و همچنين دقت زيادي مي كنند كه محصولاتشان طبق اين مدلها و توصيفها ساخته شوند. مدلهاي خوب و دقيق در برقراري يك ارتباط كامل بين افراد پروژه، نقش زيادي مي توانند داشته باشند. شايد علت مدل كردن سيستمهاي پيچيده اين باشد كه تمامي آن را نمي توان يك باره مجسم كرد، بنابراين براي فهم كامل سيستم و يافتن و نمايش ارتباط بين قسمتهاي مختلف آن، به مدلسازي مي‌پردازيم
ابزارهاي مورد استفاده براي هر رويكرد چه ابزارهايي مي باشد؟ مدلسازی کسب و کار :ابزار BPMN مدلسازی سیستمیزبان UML –استفاده از نرم افزار STELLA تا چه اندازه بايد به مدلسازي كسب و كار اهميت داد ؟
1 - برای آگاهی بهتر از مکانیزم های موجود در کسب و کار 2 - برای انجام تغییرات و بهینه سازی اساسی ساختار فعلی کسب و کار و فعالیت های آن 3 - برای نمایش ساختار یک کسب و کار جدید 4 - برای تجربه یک شیوه جدید در کسب و کار و با برای کپی و مطالعه شیوه های مورد استفاه توسط رقیب ها 5 - برای شناسایی موقعیت های برونسپاری در جهان امروز طراحی مدل های کسب وکار به طور فزاینده ای از اهمیت برخوردار شده است چرا که استراتژی ها به آسانی قابل تقلید و تکرار شده اند. ابداع یک مدل کسب و کار نمایانگر حد بالای تغییرات در ابداع محصولات یا فرایند های جدید است. با بهره گیری از مزیت های رقابتی مختلف یک مدل کسب و کار جدید می تواند باعث پرش و جهش قابل توجهی در رقابت های اقتصادی باشد. |
25 نظر
محمد زند / 10 شب / 5 دی 1395, / جواب
ارسال آرشیو محتوا
محمد زند / 10 شب / 5 دی 1395, / جواب
محتوای ارسالی از آرشیو 1393